# 009 sarmango finops

# FinOps - com Sarmanho

27 de jan. de 2026

Convidados Deo Carlos Marcello Pontes Bruno Ricardo

Registros da reunião Transcrição

# Resumo

Marcelo Pontes, Deo Carlos e Leonardo Sarmanho discutiram a construção de uma visão de arquitetura de dados com foco inicial em FinOps, priorizando o problema de conciliação por ser a maior dor em termos de dados. Leonardo Sarmanho detalhou os principais desafios práticos, incluindo dados de pagamento incorretos na conciliação, a complexidade desnecessária do pipeline de dados em Spark/GCP e a inconfiabilidade do histórico de dados. Os participantes também analisaram o processo operacional e os sistemas envolvidos na conciliação com a gestora Milênio.

Marcello Pontes questionou Deo Carlos e Leonardo Sarmanho sobre os desafios e solicitou que eles detalhassem as dores e fontes de dados por escrito para iniciar o trabalho, propondo que uma estrutura futura deve permitir o "time travel" dos dados. Leonardo Sarmanho se ofereceu para enviar a Marcello Pontes o código do job PAP Par e a documentação do webhook de retorno da Milênio, essenciais para a compreensão do processo e a validação dos dados.

# Detalhes

Visão Geral e Escopo do Projeto Marcelo Pontes iniciou a conversa delineando a meta de construir uma grande visão de arquitetura de dados para operação e governança de dados. Eles mencionaram que o foco inicial será em FinOps e atendimento, atacando o menor problema possível que agregue valor dentro de FinOps (00:00:00). Marcelo Pontes afirmou que estão finalizando a primeira versão da documentação da visão de arquitetura e que a implementação deve começar o mais cedo possível (00:01:18).
Desafios Práticos de Implementação Marcello Pontes questionou Deo Carlos e Leonardo Sarmanho sobre os desafios práticos, os sistemas envolvidos, e as implementações vislumbradas para o futuro imediato e longo prazo (00:01:18). Eles expressaram a necessidade de entender os sistemas, as dores e as consultas, solicitando que a equipe detalhe essas informações por escrito para que possam começar a trabalhar. Leonardo Sarmanho se propôs a detalhar os tópicos, incluindo dores, desafios, sistemas e fontes de dados (00:02:23).
Blocos de Problemas em FinOps Leonardo Sarmanho explicou que o problema de FinOps se divide em dois grandes blocos: a parte de cessão de crédito (transformação de empréstimos em CCBs) e a parte de conciliação (carimbar pagamentos de contratos para identificar sua origem e propósito). Eles decidiram focar na conciliação, pois é a maior dor em termos de dados e urgência que precisa ser atacada rapidamente (00:03:30).
Desafios na Construção de Informação para Conciliação A conciliação envolve a construção de um arquivo com dados internos, como IDs de boletos, informações de pagamento, e propostas, que é enviado à gestora (principalmente Milênio e Verte) (00:04:55). Marcello Pontes questionou se cada gestora tem um formato diferente, e Deo Carlos e Leonardo Sarmanho confirmaram que sim, mas que o foco é a Milênio, que é onde está a maioria dos fundos (00:06:11).
Primeira Dor: Informação Incorreta de Pagamento Leonardo Sarmanho identificou uma dor crucial na conciliação: o dado de pagamento em algumas tabelas está incorreto quando confrontado com o dado do boleto, levando ao envio de informação divergente para a gestora. Eles mencionaram que a informação correta do boleto é fornecida pelo provedor principal, e que seria possível coletar diretamente dessa fonte, já que a informação correta já existe internamente (00:07:28).
Segunda Dor: Complexidade do Pipeline de Dados A segunda dor levantada é a complexidade do pipeline de dados de conciliação, que é construído em Spark na infraestrutura GCP. Leonardo Sarmanho e Deo Carlos concordaram que a estrutura é mais complexa do que o necessário, com regras de negócio e lógicas espalhadas, o que torna a manutenção e a consulta difíceis. A simplificação das transformações em tabelas mais simples e consultáveis ajudaria a resolver a complexidade da estrutura (00:08:49).
Terceira Dor: Inconfiabilidade do Histórico de Dados A terceira dor é a falta de confiabilidade no histórico de dados, o que impede a correção de problemas passados de forma assertiva. Marcello Pontes perguntou se a equipe esperava corrigir dados enviados no passado, mas Leonardo Sarmanho e Deo Carlos concordaram que o foco deveria ser fazer o processo corretamente daqui para frente (00:11:46). Eles argumentaram que o crescimento futuro dos dados tornará o histórico anterior cada vez menos relevante (00:13:12).
Abordagem Futura e Estrutura de Dados Deo Carlos e Marcello Pontes discutiram a necessidade de uma estrutura de informação futura que permita o "time travel", ou seja, a capacidade de entender exatamente o estado dos dados em uma determinada data, mesmo que as bases não sejam imutáveis, garantindo que as alterações preservem a informação. Marcello Pontes sugeriu que fazer o correto agora permitirá esse time travel (00:14:26).
Desafio Operacional do Processo de Conciliação Leonardo Sarmanho descreveu o processo operacional da conciliação como custoso, envolvendo rotinas diárias de consulta, transformação e envio de informações (00:14:26). Eles precisam de um processo que permita a consulta e a identificação de problemas de forma rápida, bem como o reenvio tempestivo de informações, já que há um tempo limite para o envio (cerca de 4 da tarde) (00:15:41).
Fluxo de Envio e Resposta da Gestora O processo de envio de dados é interativo, com o arquivo sendo gerado em formato CSV (00:16:54). Um serviço interno envia o arquivo via upload de API (e não por escuta de bucket da gestora) para a Milênio. A gestora processa o arquivo e retorna os resultados (eventos de processing, invalidated, completed, ou erros específicos) via webhook (00:27:43) (00:37:16). Deo Carlos notou que pode haver múltiplas interações de ajuste e reenvio no dia (00:16:54).
Sistemas e Fontes de Dados Envolvidos Os principais sistemas de integração para conciliação são o provedor de pagamentos IUGO, que fornece uma API de informações de boletos, e as APIs das gestoras (Milênio). A informação da IUGO é a mesma coletada pela gestora (00:23:47). Internamente, o sistema integra-se com buckets (para uploads) e o BigQuery (para consultas e construção de arquivos) (00:25:05).
Ajustes e Complexidade Marcello Pontes perguntou sobre a trivialidade dos ajustes necessários após o retorno do webhook. Leonardo Sarmanho classificou a correção do problema principal (valor de pagamento incorreto) como trivial, pois a informação correta existe em outras tabelas (00:41:05). No entanto, problemas mais complexos, como os relacionados à renegociação, demandam mais tempo e esforço para reconstrução e identificação (00:42:17) (00:45:37).
Complexidade da Renegociação de Contratos Deo Carlos explicou que o processo de renegociação é excessivamente complexo e desnecessário, implementado para que a área de crédito pudesse visualizar o que foi pago ou não no contrato original. O contrato original nunca morre; novas parcelas são criadas e mapeadas de volta ao contrato original (00:42:17) (00:45:37). Eles veem a renegociação como um candidato para um processo de dados derivado, assim como os pagamentos, para criar uma tabela de informações calculadas de forma correta (00:43:22).
Risco de Overfit em Infraestrutura de Correção Deo Carlos expressou preocupação de que a construção de uma infraestrutura para corrigir problemas complexos possa favorecer a continuidade das "maluquices" existentes, criando um overfit para um problema ruim (00:43:22). Marcello Pontes sugeriu que uma camada de tradução entre o sistema antigo e o novo pode ser necessária, e que é importante que a nova estrutura represente os grandes eventos contábeis (00:47:08) (00:51:16).
Outras Informações Críticas Faltantes Deo Carlos apontou que o processo interno não está salvando todas as informações que deveria, como a data em que a cessão foi efetivamente feita. Muitas vezes, é utilizada uma data próxima, mas incorreta, em processos importantes. A equipe planeja começar a salvar essas informações, transformando-as em fontes de verdade para o processo de cessão e conciliação (00:52:40).
Exemplificação Prática do Processo de Geração de Arquivos Leonardo Sarmanho demonstrou um exemplo prático da construção do arquivo CSV (enviado à gestora) através de uma query no BigQuery (00:53:58). Eles demonstraram a necessidade de fazer joins em várias tabelas (como invoice, installments e contratos/propostas). Eles reforçaram que o valor pago é extraído da tabela installments (errada) em vez da invoices (correta) (00:56:20). Ele também explicou que vários tratamentos no dado (como pagamentos duplicados ou cancelados) são feitos via código no pipeline Spark (00:57:49).
Responsabilidades e Processo do Código Leonardo Sarmanho confirmou ser o responsável por manter o código, embora dependa da engenharia para certas permissões, como um deploy. Ele descreveu o processo de construção da informação como simples, mas que exige filtrar, tratar e transformar os dados para garantir que o valor correto seja enviado e as informações coletadas e armazenadas estejam corretas, o que atualmente é um grande problema. Leonardo Sarmanho também se ofereceu para mostrar mais detalhes do código e do processo, caso Marcello Pontes quisesse (00:58:51).
Solicitação de Acesso e Informações do PAP Par Job Marcello Pontes agradeceu as informações de Leonardo Sarmanho e solicitou que ele compartilhasse o código do job PAP Par, se possível, pois seria de grande valor para entender o processo. Marcello Pontes indicou que precisará criar algo em paralelo para validar os dados do job e que Leonardo Sarmanho os ajudaria com isso. Eles discutiram as dificuldades de Marcello Pontes em acessar os repositórios, e Marcello Pontes pediu o nome do repositório ou dos repositórios relevantes para que pudesse passá-los via Slack ou e-mail, pois não conseguiu localizar Leonardo Sarmanho no Slack (01:00:09).
Compartilhamento de Recursos e Documentação Leonardo Sarmanho concordou em enviar a Marcello Pontes o código do job Park e talvez um arquivo, se fosse útil. Marcello Pontes também solicitou informações sobre o web hook de retorno, e Leonardo Sarmanho respondeu que enviaria uma documentação, notando que o web hook é um sistema mantido principalmente pela engenharia, e ele não possui tanto acesso a eles. Marcello Pontes sugeriu que Leonardo Sarmanho compartilhasse o corpo JSON do web hook apenas para contexto e mencionou que uma pasta no Drive seria um formato fácil para compartilhar esses recursos (01:02:03).

# Próximas etapas sugeridas

Marcello Pontes finalizará a documentação nesta semana para ter a primeira versão final da documentação de visão de arquitetura.
Leonardo Sarmanho enviará o código do job do PAP Par para Marcello Pontes e detalhará um pouco o job Park, talvez mandando um arquivo, via e-mail.
Leonardo Sarmanho enviará a lista dos repositórios relevantes no Slack.
Leonardo Sarmanho enviará uma pasta no Drive com a documentação do web hook e um snippet ou um corpo de JSON de retorno para Marcello Pontes.

Revise as anotações do Gemini para checar se estão corretas. Confira dicas e saiba como o Gemini faz anotações

Envie feedback sobre o uso do Gemini para criar notas breve pesquisa.

27 de jan. de 2026

# [Sync] Data Platform - Transcrição

# 00:00:00

Deo Carlos: Mas é isso, né? Então, existem existem algumas outras outras etapas do trabalho, mas tipo essa é a primeira, né? Essa é o primeiro passo e enfim, me parece que é um que é que fazer logo esse primeiro passo seria uma coisa interessante para para essa plataforma e enfim e obviamente vão ter que enfim fazer outras coisas também, né? Possivelmente se se quiser a gente já fez aquele pequeno documentozinho assim falando de
Marcello Pontes: Certo.
Leonardo Sarmanho: Угу.
Deo Carlos: alguns outros pontos que onde poderia ser ser feito, né? Mas se a gente quiser começar de uma forma um pouco mais focada, pode começar falando disso.
Marcello Pontes: Tá. Deixa eu só fazer uma intro aqui também rapidinho, só para dizer o que que eu espero também dessa dessa introdução e e do da parte de FOPs também. Eh, o nosso trabalho aqui, eh, Léo, tá sendo construir uma grande visão do que a gente espera, eh, de arquitetura de dados pra gente operar e governar dados. daqui para frente, eh, a gente não vai conseguir fazer todo eh, resolver todos os problemas ao mesmo tempo. Então, a gente vai começar aqui por Fops e e por atendimento. A gente vai atacar, se possível, o menor problema que entregue algum valor eh dentro de Finops.

# 00:01:18

Marcello Pontes: E lógico que a gente vai começar com a visão de FINOPS, o que que a gente espera para para todo o processo de Finops, vai começar no escopo ali e vai desenvolver. Então, eh, a gente teve bastante conversa já, eu, Dé, Bruno, Léo, Wagner, Léo, Luiz, Wagner, enfim, Fernando, pessoal todo. E a gente, acho que já estabeleceu, vamos supor, premissas suficientes para como a gente quer, como a gente quer, tá? Tô finalizando essa semana a documentação paraa gente dar como a primeira versão final da documentação de visão de arquitetura com tudo que a gente espera. E aí, eh, o mais cedo possível a gente precisa, eh, começar a, eh, implementar, fazer a implementação. Já tem um projeto, inclusive, que o Fernando abriu lá, que o Wagner tá me dando permissão agora, pra gente começar algumas implementações já. Então, eu preciso entender sobre o ponto de vista de alguém que vai ajudar a a a trazer essa implementação à vida. Eh, quais são, assim, o Del já me explicou bastante quais são as dores hoje, mas e aí eh na prática, quais são, eh, os desafios de vocês em termos mais práticos, né? Eh, quais são quaisão,

# 00:02:23

Deo Carlos: Så
Marcello Pontes: quais são as implementações que vocês estão vislumbrando aqui paraa frente no no futuro imediato e e no mais longo também? Eh,
Deo Carlos: Yeah.
Marcello Pontes: quais são os sistemas, por exemplo, que vocês integram. Eh, assim, é lógico que a gente vai começar no nível mais alto, sem precisar detalhar tanto, preciso entender, preciso chegar, preciso aterrizar e depois a gente vai entrar num detalhe maior. Se vocês puderem detalhar em documentação, em forma de forma escrita, de maneira síncrona, eh, tudo que tudo que vocês sabem hoje ou pelo menos aquele e nível inicial do que vocês sabem para eu poder começar a trabalhar, porque eu vou entrar nisso aí também. Eh, bom, mas aí assim, eu preciso preciso aterrizar, né? É preciso saber quais são eh, enfim, os sistemas, as doores, as consultas, como é que como é que eu sei de bastante coisa já que o D já me falou bastante, tá? Então, eh, se tu puder dar uma pincelada aí, vai ajudar para mim.
Leonardo Sarmanho: Tá?
Marcello Pontes: Ah.
Leonardo Sarmanho: Então vou falar um pouco assim desses desses tópicos que você falou as dois, um pouco dos desafios da dos termos mais práticos, próprio, alguns sistemas e fontes de dados que a gente conversa e integra também.

# 00:03:30

Leonardo Sarmanho: Depois eu acho que eu posso mostrar um fluxo aqui, eh, olhando para bem para dados, olhando de forma bem prática para te mostrar, pelo menos para, não sei se o Del chegou a fazer isso, mas para mostrar de uma forma bem prática o que os principais problemas que a gente tem hoje, tá, Marcelo? Mas eh acho que é começando do começo, imagino que o D já tenha falado, a gente aqui na parte de Finops, a gente tem duas grandes dois grandes blocos assim que a gente eh que a gente eh se encara no dia a dia. A parte de sessão, então a parte de sessão de crédito, é quando no final das contas a gente pega o esses empréstimos, transforma nessas CCBs e os fundos compram. E a parte de conciliação é quando a gente pega os pagamentos desses desses contratos e a gente tenta, no final das contas conciliar, a gente tenta carimbar lá, falar de onde vem e o de onde vem esse dinheiro e e para qual proposta ela ela tá referida. Então, de formas de forma bem geral, a gente encara o problema de FINOP nesses dois grandes blocos, tá? Eh, eu vou falar então assim quais são, tem várias dores desses dois grandes blocos. Eu vou focar aqui na conciliação porque como a gente já também conversou bastante, eu, Del, João, eh acho que a conciliação hoje é o que a gente precisa atacar de uma forma mais rápida.

# 00:04:55

Leonardo Sarmanho: Então é o é a maior dor no sentido, não que a sessão não seja, mas é a maior dor no sentido de dados e de urgência mesmo que a gente precisa encarar, até porque isso tga outros problemas aqui na parte do crédito, tá? Então, falando da conciliação eh das dores, hoje a gente tem um um grande problema que é o seguinte. Hoje a gente tem uma uma um problema de construção de de informação. Então, o que que eu quero dizer com isso? Hoje, quando eh a conciliação se resume de uma forma bem bem simplória, é a gente constrói, no final das contas, um arquivo com dados internos e a gente envia pro pra gestora. Então esse dado tem informação de boleto, o ID do boleto, tem informação do eh de quem pagou, qual fundo, qual proposta e qual parcela e etco, tá? E no final das contas a gente constrói essa, pega esses dados, constrói no formato padrão que a gestora tá esperando que a gente envie. E a gente envia para justamente conciliar, para falar o seguinte: "Olha, aqueles R$ 20 que a gente recebeu, eh, 10 é da parcela um, cinco é da parcela dois da proposta tal e os outros cinco é da proposta tal".

# 00:06:11

Leonardo Sarmanho: Eh, pode
Marcello Pontes: Eh, cada gestora tem um formato padrão,
Leonardo Sarmanho: falar.
Marcello Pontes: você tem que fazer muitos formatos diferentes.
Leonardo Sarmanho: Hoje a gente tem duas duas gestoras, tá? Eh, principais, então, a Verte e a Milênio, sendo que a grande maioria é milênio e são formatos diferentes, tá? Eh, mas assim, o foco seria aqui mais a Milênio, que é onde tem o a maioria dos fundos, tá? E estruturas. Eh, então no
Deo Carlos: A a Millenio,
Leonardo Sarmanho: final.
Deo Carlos: ela é uma gestora que ela faz um intermédio também com outros provedores, né? Então você tem administradores, tem outras coisas que ela dá já essa normalizada nesses formatos, né? Como a gente fica entrando em contato direto com a Millennium, aí não precisa lidar com vários e vários formatos diferentes.
Leonardo Sarmanho: Isso. Isso.
Deo Carlos: A princípio, até onde fizer sentido,
Leonardo Sarmanho: Aham.
Deo Carlos: vai ser feito eh uma maneira não estupidamente cing com a milênio, né? Mas até onde fizer sentido.
Leonardo Sarmanho: É assim, eu tô falando aqui do da Milênia, mas claro que, enfim, eh, em termos gerais, assim, o dado é bem parecido em termos de formação.

# 00:07:28

Leonardo Sarmanho: Eh, mas a Milênia aceita não formato, tá? Hoje uma grande dor nossa aqui que é uma é uma é até algo de certa forma simples de de se resolver, mas que a gente tá tendo problema em termos de geração de formação, é que hoje a gente pega essa informação de uma tabela, da tabela de não sei até que ponto, Marcelo, você conhece um pouco da estrutura de dados, mas imagino que sim já, né, da
Marcello Pontes: um pouco sim, talvez não tanto, mas pode detalhar.
Leonardo Sarmanho: Tá, tá. Então eu também não vou tentar detalhar não, porque assim, não é não é tão não é tão importante nesse primeiro momento. E enfim, mas assim, aí a gente pega de algumas tabelas e dessas tabelas esse dado, o dado de pagamento, eh, por exemplo, ele tá vindo errado. Que que que isso quer dizer? é que quando a gente confronta com o dado do boleto, que o valor que foi pago de fato versus o dado que a gente tá dizendo que foi pago em algumas tabelas, esse valor tá divergente. E hoje a gente envia essa informação com o valor que eu tô chamando de errado, porque a gente tá construindo e salvando em algumas tabelas de forma errada. Eh, o principal provedor de de informação de boleto, eh, na, eh, a princípio envi essa informação correta pra gente.

# 00:08:49

Leonardo Sarmanho: A gente poderia coletar desse dessa fonte de dados e enviar para e só basicamente rotear essa informação pr pra gestora. Mas hoje a gente pega um dado gerado por nós para construir essa informação e acaba que a gente tem a a primeira dor, sim, que é a talvez a principal, é que a gente tá mandando uma informação errada, tá? Eh, hoje eu já tenho uma forma de de fazer isso, enviar essa informação correta, coletando dessa fonte de dados de boletos e a gente conseguiria já existe já essa informação correta do nosso lado, tá? Então essa é uma primeira dor nossa que foi é um sistema que foi construído usando informação que não tá correta. A segunda dor, eh, Marcelo, é assim, existe um pipeline de dados, focando agora falando de conciliação especificamente, exige um pipeline de dados construído em Park, eh, e, e, obviamente Infra GCP, que é um pipeline bem complexo para um problema que eh um problema um pouco mais simples assim de extração de dados, é uma grande ETL, né? administração de dados, transformação e e no final a gente envia um relatório pro pra gestor. Então, existe uma complexidade grande no sentido de estrutura que eu acho que hoje também é uma dor. É uma dor que eu acho que se a gente atacar lá, como o próprio D falou no início, a gente atacar colocando em tabelas mais simples eh essas transformações de uma forma mais simples e que seja fácil a consulta, porque hoje não é tão fácil por conta dos intermediários que existem nesse pipeline de dados.

# 00:10:30

Leonardo Sarmanho: ajudaria bastante a gente. Existe uma dor de eh de complexidade da da estrutura hoje que existe.
Deo Carlos: É, só complementando que que ela tá falando assim, tipo, existe uma estrutura muito mais complexa do que o necessário, né, até pelo volume de dados, pelas coisas e tal, mas também eh as próprias regras de negócio e as lógicas, elas acabam ficando espalhadas em 30 lugares diferentes, né? Então, como é que isso é feito, cara? Ninguém tem confiança bem do que é feito, aonde, por quê? Porque, tipo, existem vários pontos diferentes que mexem lógicas que são que são que tem overlap, que enfim que que dá pouca confiança entender o que exatamente se está tentando fazer, né? Então,
Leonardo Sarmanho: Isso.
Marcello Pontes: Entendi. Difícil de manter,
Leonardo Sarmanho: Что?
Deo Carlos: fazer um eh fazer esse processo de uma maneira bem mais simples e clara é
Marcello Pontes: né?
Deo Carlos: uma das coisas principais. E um dos principais problemas do processo é fonte de dado errado. Então, né, tipo, essa parte do processo que é gerar uma fonte de dado correta e e confiável, eh,
Leonardo Sarmanho: confiado.
Deo Carlos: é um primeiro passo para que depois tudo saia melhor.

# 00:11:46

Marcello Pontes: Obrigado.
Leonardo Sarmanho: E aqui é a última dor. É, é isso que o fal que o D comentou, é a questão da fonte de dados, o histórico ser confiado. Hoje a gente tem um problema de puramente de conciliação, de enviar informação correta e acaba que nosso histórico não tá confiável suficiente pra gente conseguir primeiro corrigir possíveis problemas que aconteceram ao longo do tempo. Então, quando a gente envia essa informação, a gente recebe uma série de de eventos do da parte da principalmente da milênio. E quando tem acontecem esses problemas, a gente acaba que por conta do nosso histórico, a gente não tem confiança e aí sim a gente não consegue eventualmente corrigir e atuar no problema de uma forma mais assertiva e e tempestiva, né? Então esse é um problema que realmente em termos de fonte de dado de confiança da informação, a gente não tem.
Marcello Pontes: Eh, então uma hora a gente vai corrigir isso, né? Uma hora a gente vai ter, p***, vamos ter um processo lá que vai e a gente vai confiar, vai tá, a manutenção vai est acontecendo em um lugar só, em mínimo de locais possíveis e aí o dado vai tá correto daqui paraa frente. Eh, você, a gente espera corrigir dado que foi mandado pro passado, fazer uma conciliação com o que foi mandado, por exemplo, para eventualmente tomar pelo menos ciência de eventuais diferenças ou isso não faz parte do processo?

# 00:13:12

Leonardo Sarmanho: Eh, não sei o Del pode me corrigir, mas eu acho que no primeiro momento acho que não seria bom a gente atacar já de cara em termos o histórico. Acho que se a gente conseguir daqui para frente fazer direito e aí sim depois a gente fazer direito o passado seria o
Deo Carlos: É,
Leonardo Sarmanho: ideal.
Deo Carlos: eu acho que eh eu eu acho que o a expectativa um dos principais medos da empresa é muito mais tipo crescimento se dar correto do que o que existe
Leonardo Sarmanho: M.
Deo Carlos: hoje tá correto, sabe? Então depois esse ano você vai originar mais do que todo o histórico da empresa por
Marcello Pontes: Entendi.
Deo Carlos: muito. Por muito não assim, mas razoavelmente mais. Então é muito mais importante que, tipo, o que a gente tá fazendo agora seja correto do que a gente tá correndo atrás do rabo para tentar ajustar valores que não são irrelevantes, mas que vão ser cada vez menos relevantes frente o que tá vindo. Enfim, então, sem dúvida nenhuma, cabeça assim, olhar pra frente e, tipo, fazer o mais correto daqui paraa frente e de uma hora talvez, quem sabe algum dia, eh, olhar para trás também, mas aí não vai olhar para trás sem estado paraa frente.
Marcello Pontes: Entendi. E aí,

# 00:14:26

Deo Carlos: Sim, sim.
Marcello Pontes: e pelo que eu posso imaginar fazer correto agora, permitindo um futuro time travel para agora, por exemplo, né? Não, não mais pro passado, mas pelo menos para agora, né? que a gente vai começar a fazer e permitir esse time traveling.
Deo Carlos: Não, tipo, se a estrutura de informação que a gente for fazendo agora, ela seguir, né,
Marcello Pontes: Obrigado.
Deo Carlos: essa não necessariamente que as bases vão ser imutáveis, mas que ela tem uma semântica imutável, né, que você consiga, essa semana que mutável você tá falando, né, a gente consiga ter esse time travel, que você consegue entender exatamente como estava numa data tal, não necessariamente porque nada foi alterado,
Marcello Pontes: Uhum.
Deo Carlos: mas porque as formas de alterar preservam essa informação, né? Então,
Marcello Pontes: Exatamente.
Leonardo Sarmanho: Eh, então é isso, assim, acho que de dores é isso. Eu vou falar um pouco bem rápido assim os desafios em termos práticos. Acho que assim, a gente tem uma dor hoje de forma bem prática que primeiro é um processo operacional, né? Então, existe um operacional do dia a dia, rotinas diárias que ex que exigem um assim, primeiro, a consulta dessas informações e eh a consulta, o envio dessas informações, a transformação, o envio dessas informações e a gente justamente a gente não tem tanta confiança.

# 00:15:41

Leonardo Sarmanho: Então, eh é fora o processo operacional no sentido de geração de arquivos, de reenvio de informações. Isso é uma coisa muito importante pro dia a dia do do processo de FINOPS. Isso aqui eu falo também da da sessão quando a gente for falar isso no futuro, mas na conciliação. Então é um ponto muito importante quando a gente, por exemplo, receber esses eventos da própria Milênia ou futuras gestoras, eh, que a gente receba e fala o seguinte: "Tá errado por isso?" A gente consiga de forma tempestiva corrigir, enviar, identificar fácil o problema. Eh, identificamos o problema, eh, tratamos o problema, corrigimos e reenviamos. Então esse processo hoje em dia é um processo bem bem custoso, eh, que e é uma uma dor bem prática hoje em dia, assim, é uma é algo bem operacional e que deveria ser um mais fácil e hoje não é. Então, consulta de informação rápida, identificação de problema de forma rápida e o reenvio de uma forma rápida também dessas informações. Eu falo rápido porque é um processo, como eu falei, é uma execional que tem um tempo de de envio. Então, a gente tem até mais ou menos 3 da tarde, na verdade até 4: da tarde, mas eles pedem em geral.

# 00:16:54

Marcello Pontes: O formato, o formato que vocês enviam é formato de dados estruturados, imagino, né?
Leonardo Sarmanho: é um CSV, né? A gente envia um CSV para eles. Então, a gente faz uma requisição eh no end point, falando especificamente da Milen, tá? a gente pega, gera esses arquivos, faz uma requisição no no end point deles e aí se intriga toda o processo, o fluxo de de eventos lá do lado deles.
Deo Carlos: É, eu, eu particularmente penso nesse processo eh de uma forma pelo menos eh alguns passos bem parecidos com pipeline de dados, mas ele não é puramente só esse, porque existe um pouco mais de interação no seguinte sentido, ele gerou o arquivo, ele faz o envio, eh, pode se esperar, talvez 100% dos casos no futuro, eh, que vai existir alguma coisa depois disso que vai precisar ser ajustado,
Leonardo Sarmanho: M.
Deo Carlos: mudança de fundos ou correções ou o que seja. Eh, e vai ser feito esse processo novamente. E, enfim, potencialmente eu não não sei até quantas interações você costuma fazer, mas enfim, potencialmente vão existir eh uma, duas, três, quatro interações no dia, às vezes para que esse processo seja totalmente finalizado. Eh, a gente espera que cada vez mais, né, as coisas estejam mais redondas, então em volumes absolutos, eh, isso diminua, mas até por problemas que a gente não consegue controlar da própria, da própria milênium ou do dos próprios parceiros, vez outra vão existir problemas, mesmo se a gente tiver fazendo tudo redondo, vai continuar existindo problema.

# 00:18:46

Deo Carlos: Então, grande parte desse processo, ele vai ser uma coisa relativamente interativa, né? Então, eh, existe existem fontes de dados fontes da verdade assim que que são dados e tal, mas a gente transformar esse dado para mud final para enviar, depois a gente vai ter que pegar isso com a resposta, gerar um novo eh dado para ser enviado e seguir fazendo isso até tudo ser finalizado. M.
Marcello Pontes: Eh,
Leonardo Sarmanho: quer falar assim.
Marcello Pontes: a a depender, é lógico que a depender muito do processo de ajuste que vocês fazem quando precisam deixa quando quando precisa fazer alguma alteração, por exemplo, eh, um cenário que eu imagino, um workflow que eu imagino, é que a gente tenha, sei lá, algumas fontes de dados, que o operador que vai fazer esse ajuste, por exemplo, possa fazer esse ajuste da maneira mais parametrizada possível, né? Imagina que eh eu possa expressar essa esse ajuste na maneira de de filtro no D. Então vamos imaginar que o dado por trás que a gente vai enviar, ele alimente um DAR que a gente veja as métricas gerais ali, o somatório geral, algumas médias geral, alguma coisa assim, alguma métrica, eh eh que sumarize tudo estatisticamente e aí ah,
Leonardo Sarmanho: อ
Marcello Pontes: p***, eu inclui um negócio aqui que não era para inglês.

# 00:20:10

Marcello Pontes: Se a gente puder fazer isso parametricamente, eu imagino que isso seja, ó, a gente tem a a nossa fonte da verdade agora bem estruturada, tem o processo de ET, todos os processos que que desagam nessa base de dados, vamos imaginar um tabelão só para exercício. E aí o grande didáico dessas médicas,
Leonardo Sarmanho: Mhm.
Marcello Pontes: a o fundo a sei lá, era para ter enviado, tá imaginando, tá? Era para ter enviado, sei lá, 3 milhões, sai 3.2. 200.000 é disso aqui, esse filtro aqui que não tá. Então a gente, ah, o fil, sei lá, parametriza a ferramenta lá e clica no botão, ele vai gerar um arquivo, outro arquivo. E aí esse outro arquivo, sei lá, e aí você cria um processo que é automatizado suficiente, mas ainda permite o o a pessoa no meio do caminho para poder validar e dar OK daquilo ali, né? Eh, enfim. Poderia ser um negócio assim, se a realidade permitir.
Leonardo Sarmanho: É, acho que a ideia é essa e isso de forma interativa, né? Então, quando a gente enviou o primeiro arquivo, recebemos alguns eventos e a gente viu que tinha algum problema, a gente consegue filtrar novamente, fazer esse check novo com o agora com como é paramétrico, né?

# 00:21:14

Leonardo Sarmanho: Então, a gente vai fazer o check novamente, ver a informação nova sendo eh eh conciliada e assim por diante. Чи
Deo Carlos: E só só para manter o espírito assim, né, do de de como isso vai aconte como isso Isso acontece, né? Tipo, existe um sistema que roda hoje. Eh, e esses isso que o que que o Léo tá construindo é um sistema mais ou menos para tá observando o sistema que roda hoje e vendo que as coisas estão indo mais ou menos de acordo para num segundo passo se substituir o sistema que está rodando. E por exemplo, você tendo um sistema que tá observando as coisas e tal, não sei o quê, eh já vai ser algo que vai dar muito mais confiança quando você for começar a fazer um handover de um sistema para outro e para que essas coisas eh tenham confiança de que isso está funcionando
Leonardo Sarmanho: M.
Deo Carlos: direitinho, né? Então esse sistema que funciona hoje nesse nesse formato vai ser muito isso ainda. Você vai migrar para um novo sistema num formato muito, num espírito muito parecido com esse e a partir daí você vai começar a ver, não dá para automatizar muito mais aqui, dá para lidar com isso aqui melhor. Agora a gente tem muito mais informação, então essa classe de erros aqui vai ser menor.

# 00:22:34

Deo Carlos: Enfim, então eh é mais ou menos assim que se espera caminhar com isso. Eh, perfeito.
Leonardo Sarmanho: Perfeito, perfeito. É isso. Assim, até para complementar o Delmacel, acho que a ideia aqui, como eu falei, a primeira dor que eu falei é justamente a confiança nos dados, essa questão de envio de informação errada. Eh, foi um, é um problema que para mim é um problema bem, é simples no sentido de a gente sabe que existeonde existe a informação, correta, mas é um problema grave, porque a gente tá cometendo isso todos os dias, a gente tá enviando uma informação errada. E a quando a gente estava conversando, fazendo as nossas interações aqui internamente, eh, a gente levantou esse ponto. Seria muito bom a gente ter essa fonte da verdade, a gente tem essa fonte que a gente consulta de uma forma simples e e a gente confia. É isso. A gente sabe que a gente vai lá e a gente sabe que tem informação correta. Eh, e sem intermediário, sem reconstrução, a gente sabe que ali tá a fonte correta pra gente.
Marcello Pontes: Patrão.
Leonardo Sarmanho: Eh, então é isso. Então, eh, eu falei um pouco dos desafios e agora, só para finalizar também de uma forma bem rápida, eu vou falar dos sistemas eh que a gente integra.

# 00:23:47

Leonardo Sarmanho: Hoje a gente tem eh a parte de de eh conciliação especificamente, tá? A gente hoje coleta informações de pagamentos. A gente, a maioria dos pagamentos aqui, se não todos, eh, são feitos via boleto. E a gente consulta essas informações na um provedor chamado IUGO. Então, a IUGO fornece uma API, uma API que a gente coleta essas informações.
Marcello Pontes: Desculpa. Qual, qual é o?
Leonardo Sarmanho: É, e UGO e IU, é IU GU. Eh, e essa essas informações que a gente tem de quanto que foi pago um determinado boleto. Essa informação, existe um ID referente a isso e a gestora também coleta dessa mesma fonte. Então, eles coletam lá as mesmas informações eh em termos de de dado bruto, né? Eles coletam e a gente coleta aqui também. Aí existe um trabalho interno de fazer o match de informações aí da engenharia, que é pegar esse ID da Yugo, então e destrinchar entre o que foi pago dentro dessa parcela. Então o ID da Yugin fornece lá pra gente aqui internamente fala o seguinte: "Olha, esse valor foi pago tanto para essa parcela, tanto para essa parcela e assim por diante." Isso é salvo numa tabela interna

# 00:25:05

Leonardo Sarmanho: nossa.
Marcello Pontes: E aí isso tem existe esse distinçamento entre pagamento, sei lá, valor original, principal, juro, juro de mora, multa, tem existe registramento só interno? Ja.
Leonardo Sarmanho: Eh, existe, existe sim essa, essa informação. Eh, eu confesso que assim, essa é uma informação que eu nunca cheguei a validar 100%, porque para nós aqui o o valor pago já tá com problema. Então, essas informações, a própria gestora, eu não sei até que ponto eles validam também, mas sim, existe essa informação, juros de atraso, uma hora e etc. Então, eh, a gente coleta, então a primeira integração seria a fonte de dados de pagamentos. Então, essa primeira informação que a gente coleta, eh, primeiro sistema que a gente integra, desculpa. O segundo sistema, o grande sistema que a gente integra, eh, é com a gestora. Então, como eu falei, a gente nós somos plugados lá no em API, em APIs dele, API Rh normal normais, que a gente envia essas informações de arquivo, a gente recebe esses eventos via um hook que a gente tem internamente e eles alimentam eh no nosso nos alimentam com as com as informações de eventos e claro o nosso sistema interno aqui que a gente tem que integrar com os buckets que a gente tem hoje em dia que a gente sobe os arquivos com as com no big quer que a gente faz as queries pra gente construir esses arquivos e assim por diante, tá?

# 00:26:37

Leonardo Sarmanho: Então, hoje, em termos de conciliação, eh, são esses dois grandes sistemas, assim de pagamentos e de gestoras, de gestoras, né? Eh, mas a gestora hoje em dia principal que a gente que a gente conecta e que a gente tá integrado, a gente precisa fazer esse match para para enviar as informações, tá? Eh, acho que assim, Marcelo, pelo que eu anotei aqui das suas das perguntas, eu anotei isso. Eu não sei se você tem mais alguma pergunta antes de eu poder passar um pouco de uma forma bem prática aqui como acontece hoje. Não sei se você tem mais alguma pergunta, mais algum ponto que queira que você queira,
Marcello Pontes: por hora não. Obrigado pelo teu esclarecimento aí. Eh, pode partir pro pro ponto prático aí assim que tu puder.
Leonardo Sarmanho: tá?
Marcello Pontes: Assim,
Leonardo Sarmanho: Então,
Marcello Pontes: eu tô eu tô eu tô tranquilo de tempo aqui,
Leonardo Sarmanho: beleza.
Marcello Pontes: tá? Teoricamente já teria passado a hora da reunião, mas eu tô tranquilo, pode ficar à vontade.
Leonardo Sarmanho: Tá. Eh, Del, você quer falar alguma coisa antes ou eu posso já mostrar aqui?

# 00:27:43

Leonardo Sarmanho: Então, o que eu vou fazer, Marcelo, aqui é te mostrar, antes de entrar até no dado mesmo, nas tabelas, eu vou só te mostrar um pouco do fluxo, como acontece hoje, e aí a gente parte para mostrar as tabelas, tá? Então, vou compartilhar minha tela. Eh, como eu falei, tentar fazer de uma forma bem prática aqui para começar por por aqui. Aí depois eu vou passando um pouco por cada etapa aí de dados, de informações e etc. Eu vou começar por pelo pelos logs, eh, porque eu acho mais fácil só tá um pouco mais claro assim do que tá enviando, que tá recebendo e assim por diante. Então, o hoje como é que funciona? Quando a gente, como eu falei, a gente tá plugado lá, na verdade eles são plugados no nosso web hook a Millenium, e a gente recebe essas várias, esses vários eventos deles dizendo o seguinte: "Olha, esses arquivos que vocês enviaram tão bons? Não tão? Eh, dentro desses arquivos, essas propostas que são essas CCBs, tão corretas ou não tão? For foram validadas ou não foram? Depois eu também entro em detalhe em termos de eventos e o que cada um deles significam, mas aqui eu vou passar em bem em linhas gerais, tá?

# 00:29:08

Leonardo Sarmanho: Então, por exemplo, esse evento aqui que a gente recebeu de sermente a baixa, então é a conciliação. Quando a gente fala de conselhação, a gente tá pensando nas baixas e a gente recebe um evento aqui que nesse arquivo que eu enviei, a gente envia, a gente enviou 156 baixas, ou seja, 156 eh pares de proposta e parcela que estão que foram aprovadas, ou seja, que foram aceitas do lado da gestora. Eu vou pegar um caso aqui com algumas reprovações para eu te mostrar. Então, pronto. Aqui foi um arquivo maior que a gente mandou 3.000 3.000 baixas. Eu vou mostrar o que que significa essa baixa, mas só quero mostrar isso aqui antes para ver a cara do do que a gente recebe.
Marcello Pontes: Tá, uma pergunta bem técnica,
Leonardo Sarmanho: E aqui a gente mostra.
Marcello Pontes: desculpa, uma pergunta bem técnica. É, isso é log de aplicação. E aí tu tá vendo o o log do retorno do webhook que eles mandam pra gente.
Leonardo Sarmanho: Exato. Exatamente.
Marcello Pontes: Obrigado.
Leonardo Sarmanho: E aqui, por exemplo, ele tá dizendo o seguinte: "Olha, tá vendo esse essa CCB, essa proposta aqui com essa parcela, ela teve um problema, que foi essa mensagem que a gente recebe deles." Eu também acho que não vale a pena entrar tanto no detalhe

# 00:30:21

Leonardo Sarmanho: agora do do das mensagens, porque aqui vai ter uma uma série de mensagem. Pode
Deo Carlos: Uma dúvida só.
Leonardo Sarmanho: falar.
Deo Carlos: Eh, esses eventos hoje em dia são persistidos numa tabela, numa filha, em algum lugar?
Leonardo Sarmanho: São aí agora, ô Del, eu não posso, não vou ter informação suficiente para te falar tudo, mas são sim. É uma tabela de output, é um outbox mesmo que a gente consegue consultar, mas eu não sei quanto tempo eh fica disponível pra gente,
Deo Carlos: Você
Leonardo Sarmanho: tá? Eh, então existe
Deo Carlos: acha, você acha que tipo essa tabela não,
Leonardo Sarmanho: sim,
Deo Carlos: ela eles vão limpando ela? É isso?
Leonardo Sarmanho: eu acho que sim. Eu acho que sim.
Deo Carlos: Mas você nunca você nunca consultou lá nas tabelas, você nunca acessou ela
Leonardo Sarmanho: Então não,
Deo Carlos: diretamente.
Leonardo Sarmanho: porque eh tanto que até via código eu bato direto
Deo Carlos: Sempre fazia assim,
Leonardo Sarmanho: no
Deo Carlos: né? Ele ficava olhando os logs do sistema, né? Esse log aí que ele ficava olhando,
Leonardo Sarmanho: Exato.
Deo Carlos: né?
Leonardo Sarmanho: E também eu consigo consultar, eu bater direto no nesse logs explorer.

# 00:31:18

Leonardo Sarmanho: Então, eh,
Deo Carlos: Так.
Leonardo Sarmanho: via código também, eu nunca cheguei a bater, já fiz squares nessa bela, mas como eu falei, em termos de temporalmente, eu não sei se eles apagam, não apagam, coisa desse tipo, tá?
Marcello Pontes: Essa tabela fica onde? Eh,
Leonardo Sarmanho: Depois eu eu vejo corretamente qual o projeto que tá, eu te passo.
Marcello Pontes: ah, tranquilo. Não, só para saber qual é a tecnologia,
Leonardo Sarmanho: Pode ser.
Marcello Pontes: se bigquer, se é SQL, pô.
Leonardo Sarmanho: Eu consulto no Big Query agora, não tenho certeza se tá no pushers.
Marcello Pontes: Valeu, obrigado.
Leonardo Sarmanho: Eh, então aqui eh aqui foi um exemplo de uma proposta, o par proposta parcela que foi reprovada. E aqui é o primeiro ponto. A gente eh acho que deveria deveria não, a gente tem que pegar essa informação e persistir no nosso banco justamente para aquele ponto que eu falei no início de tentar reenviar, de identificar o problema, por que tá dando esse problema, mapeamento de problemas e falar o seguinte: "Olha, isso aqui aconteceu por esse motivo." esse cara, esse problema especificamente é é aquilo que eu comentei mais cedo que a gente mandou o valor de pagamento errado, gente, o valor eh o valor tá diferente do que eles estavam esperando.

# 00:32:29

Leonardo Sarmanho: Então esse é um tipo de problema. Eh, tá certo? Então, vou mostrar a cara de um de um de um arquivo que é que é gerado hoje. Então, como eu falei, eh, existe um existe um pipeline lá em Spark que gera esses arquivos e, eh, e todos os dias, numa rotina de 9 da 8:30 da manhã, eh, processado, eh, são processados os dados e geram esses esses arquivos aqui, CSV com eh com as informações de baixo, tá? Então, deixa eu mostrar a cara dele aqui. Eh, eh, como eu falei, a gente enviou o ID da CCB, ou seja, aquela proposta, aquela proposta que eh foi paga nesse ID, que que aqui eles pedem o ID da Yugo. Então, no final, eh, o o ID do boleto. Então, esse aqui é o ID do boleto, a parcela e a proposta e a parcela que estavam nesse boleto, o valor pago, a data que foi paga, eh o tipo de pagamento. Então, isso aqui a gente tem dois tipos principais de pagamentos que são em voice na loja. Acho que também não vale a pena entrar no detalhe aqui.

# 00:34:18

Leonardo Sarmanho: Eh, o método de pagamento é só um ID do lado deles e algumas informações aqui, como você até perguntou. Ah, tem também informação de juros, multa e mó também tem. Então, a gente coleta, coloca isso na informação e envia essa, esse arquivo para eles. Então, o arquivo gerado é esse cara aqui. Eh, e essa informação é o é o extrato do que a gente processou lá internamente e gerou para enviar para eles, tá? pontos importantes.
Marcello Pontes: Beleza. Tô achando, tô achando só curioso aí porque o valor dessa linha que tu tá selecionado é 79,
Leonardo Sarmanho: Então,
Marcello Pontes: valor pago e aí, ah, tá, tá só juros, tá faltando principal aí pro Beleza, beleza. Eu achei que tava o principal.
Leonardo Sarmanho: e enfim, tem outras informações também que eu acho que se a gente for entrar eh vai demorar, mas no final das contas a gente é um arquivo bem de certa forma simples que a gente coloca um o ID da do boleto, qual parcela e qual proposta a gente tá dizendo que tá sendo que for foi paga e o valor que foi pago eh efetivamente, tá? Então, eh, no final das contas, a gente envia isso para eles, a gente recebe esses eventos e aí sim a gente vai dizer o que foi, eles vão, o fundo vai saber o que foi conciliado do lado deles para pegar esse dinheiro e dar baixa no na nessa proposta eh do lado do fundo e aí sim tirar isso do estoque e aí a gente seguir nossa vida.

# 00:35:59

Leonardo Sarmanho: Um um problema que acontece, se a gente mandar esse arquivo errado, é que essa esse ativo vai ficar no estoque lá do lado da nossa da gestora e pra gente a gente tá dando como baixa e para eles estar dizendo: "Olha, não, esse esse ativo não foi não foi pago, essa essa parcela não foi pago, então gera PDD, gera atraso e etc." Então, é um é um processo que ele ele é bem importante nesse sentido de estoque está correto para validação desse tipo de informação. E hoje a gente tem esse tipo de problema assim de envio de, por exemplo, de valor com reto e etc. Tá? Eh, tá? Então, vamos lá. termos bem práticos assim,
Marcello Pontes: Eh
Leonardo Sarmanho: 8:30 da manhã, esse arquivo é gerado, eh, é colocado nesse bucket, tá? A gente eh é inserido no bucket, a a criação de de arquivos dentro desse bucket é trigado eh o processo de envio de informações eh do do lado da gestora.
Marcello Pontes: Yeah.
Leonardo Sarmanho: E aí sim acontece isso.
Marcello Pontes: processo deles,
Leonardo Sarmanho: E aí sim a a gente faz o upload do arquivo,
Marcello Pontes: né?
Leonardo Sarmanho: eh, e aí começa o processo lá internamente.

# 00:37:16

Leonardo Sarmanho: Então, a gente recebe eh a gente recebe aqui um processing, invalidated e um completed, dentre outras outras outros eventos
Marcello Pontes: Ô, cara, entendi. Então, o processo é tu resumidamente bota um arquivo no bucket. Aí eles têm um processo lá que tá escutando o bucket e aí geral pegar isso aqui, processi e tal.
Leonardo Sarmanho: tá
Marcello Pontes: dentro do processo deles lá internamente eles geram o resultado desse processamento, chama o web hook para isso aqui e dá relatório de tudo que aconteceu pelo web
Leonardo Sarmanho: batendo
Marcello Pontes: hook. Imagine que ele possa chamar várias vezes o o o web hook para uma camada,
Leonardo Sarmanho: várias
Marcello Pontes: um arquivo grande, né?
Leonardo Sarmanho: vezes.
Marcello Pontes: E aí a gente eh processa o resultado dos hooks via logo aqui. Beleza?
Leonardo Sarmanho: É aí só um só uma uma correção,
Marcello Pontes: Tá?
Leonardo Sarmanho: é que assim, o processo deles é puramente, a nossa comunicação é puramente via APIs. Então, a gente existe um serviço nosso que fica escutando, fica vendo eh a o que fica lendo o o nosso bucket para enviar para eles. Então,
Marcello Pontes: Ah, entendi.
Leonardo Sarmanho: existe um serviço intermediário nosso para enviar.

# 00:38:31

Marcello Pontes: Então, entendi. E esse é nosso,
Leonardo Sarmanho: Eles não olham nada nosso interno.
Marcello Pontes: né, que faz. Entendi, entendi, entendi.
Leonardo Sarmanho: Isso é nosso. Exatamente. Existe um serviço nosso aqui,
Marcello Pontes: Beleza.
Leonardo Sarmanho: é que a gente faz esse faz a interface entre arquivos que estão no nosso bucket para fazer o upload na na PI deles.
Marcello Pontes: Beleza.
Leonardo Sarmanho: Beleza? Tá.
Deo Carlos: Só, só pergunta,
Marcello Pontes: Padrão.
Deo Carlos: Léo. Eh, a a chamada na PI é para você dar um upload no arquivo mesmo ou é porque ele vai lá e vai transformando o arquivo em chamadas rest ou que
Leonardo Sarmanho: É um upload mesmo,
Deo Carlos: seja de
Leonardo Sarmanho: cara. Existe um post aqui. Existe um post que é um upload de arquivos.
Deo Carlos: um documento?
Leonardo Sarmanho: Esse aqui é só o swager deles, tá? Então é, tá aproveitando, a gente faz o upload, a gente faz a chamada post no no document aqui é aqui a gente chama o sell, então chama o o end point de baixa, enviamos para eles, a gente recebe viw web hook, que é mais ou menos a cara desse evento aqui, eh, desse desse end point aqui, que a gente recebe o o detalhamento de todo o processo que foi feito lá.

# 00:39:49

Leonardo Sarmanho: lá do lado deles, tá?
Marcello Pontes: E aí, tu tem que tá, tu tá, tem que tá dentro de uma VPN ou tem uma autorização especial para acessar esse URL aí, que eu não tô conseguindo aqui não.
Leonardo Sarmanho: É, tem eh a gente tem um client ID e um e um
Marcello Pontes: Boa.
Leonardo Sarmanho: client.
Marcello Pontes: Não, eu não preciso de acesso não. Tava só tentando validar a segurança.
Leonardo Sarmanho: Boa, boa.
Marcello Pontes: Beleza.
Leonardo Sarmanho: Ah, tem um client ID e um client. Eh,
Marcello Pontes: Legal.
Leonardo Sarmanho: beleza. Então, agora eu vou eu vou entrar mais um detalhe aqui, mas em linhas gerais é isso, eh, geração de arquivos, chamada de de APIs e recebimento de informações. Acho que um ponto importante aqui, eh, a coleta de informações desse web Hook ser feita de uma forma melhor. Então, a gente coletar melhor, a gente identificar melhor qual foi o problema, para qual proposta, para qual parcela, coletar essas informações, eh, e tratar isso internamente. e o reenvio de informações. Então, geração de arquivos hoje é feito de uma forma não muito padrão assim, no sentido de uma forma fácil pra gente reenviar o que foi, por exemplo, aquela aquela aquela aquele erro que aconteceu hoje e e assim por diante, tá?

# 00:41:05

Deo Carlos: Ка.
Leonardo Sarmanho: Eh,
Marcello Pontes: Tá.
Leonardo Sarmanho: Eh
Marcello Pontes: Eh, só uma pergunta, desculpa. O quão trivial é o quão trivial é o quão triviais são os ajustes que vocês precisam fazer quando vem um retorno e precisa fazer algum ajuste? É alguma coisa muito complicada de fazer?
Deo Carlos: M.
Marcello Pontes: Me descreve tipo um caso simples de ajuste que precisam fazer.
Leonardo Sarmanho: Tá, assim, tem vários tipos de problemas, obviamente tem desde os mais um pouco mais chatinhos assim até os mais tranquilos. o problema que mais acontece hoje,
Marcello Pontes: Угу.
Leonardo Sarmanho: que é o valor, o pagamento errado, o valor errado, eh esse é um cara, assim, eu vou falar que é um ajuste trivial a ser feito, porque a gente tem informação correta em outras tabelas que hoje a gente não consulta quando a gente vai construir o arquivo e as informações no final das contas e enviar.
Marcello Pontes: Угу.
Leonardo Sarmanho: Então eu falo que é trivial, porque a gente tem informação e a gente consegue ajustar isso de uma forma simples, tá? Esse é o principal problema, o que acontece mais, o que eu quero dizer é que é uma é um é trivialmente resolvido, porque a gente tem informação e a gente consegue conseguiria reenviar.

# 00:42:17

Marcello Pontes: Так.
Deo Carlos: Eu
Leonardo Sarmanho: Agora tem problemas um pouco mais complexos. Eh, existe uma eu não quis entrar no detalhe agora, mas existe a parte de renegociação também. Não sei se o D chegou a falar sobre o problema de renegociação internamente, mas mas assim, a renegociação, o o processo de renegociação, ele é um pouquinho diferente. Eh, pode falar aí.
Deo Carlos: não ia levantar a mão não. Ia deixar no m só para não atrapalhar e acabei atrapalhando mais. M.
Leonardo Sarmanho: Eh, vou dar um outro exemplo. Você pediu um exemplo. Essa página de renegociação, eh, que eu não queria falar porque esse é um problema que vai demandar um tempinho. É um problema, não é muito, não é muito complexo,
Marcello Pontes: Não, eh, vou vou
Leonardo Sarmanho: tá?
Deo Carlos: Então, mas só para passar o espírito aqui,
Leonardo Sarmanho: Mais
Deo Carlos: tipo assim, eh a a eh no no num num passado quando foram eh modelar essa questão de renegociação, modelaram ela muito relativo assim, o crédito precisa ver as informações dessa forma. Então vamos fazer o nosso processo de renegociação dessa forma que precisa ser visto no final.

# 00:43:22

Deo Carlos: Então existem enormes complexidades desnecessárias em relação a isso e tal, mas eh de uma forma bem mais complexa do que dessa dessa de pagamentos, ele é um excelente candidato para a mesma coisa que é tipo, vamos pegar os dados e criar uma informação, uma tabela de renegociações e, enfim, uma tabela onde a gente tem esse tipo de informação eh calculado no formato que deveria ser a partir das informações que existem. assim, sabe? Então, é um excelente candidato para fazer isso. Só que seria, vai ser um trabalho super complexo e tem um risco de não dá nem 100% certo. Isso tem um risco e não dá 100% certo isso, que a gente tem todas as informações necessárias, mas provavelmente a gente consegue fazer isso com um um alto nível de confiança. Um outro caso, o negócio vai ficar ali meio zoado, mas vai ser muito melhor do que existe hoje, né? Então ele é um grande candidato para para isso também. E só só até uma coisa assim, eu não sei qual a experiência do Marcelo nesse nesse aspecto. O meu principal medo sobre esse tipo de coisa é tipo você ir criando essa infraestrutura eh
Leonardo Sarmanho: Ja.
Deo Carlos: que vai corrigindo esse tipo de coisa e que vai talvez favorecer com que a maluquice que que exista hoje continue existindo, né?

# 00:44:40

Deo Carlos: Porque tipo, vai ter um sistema fazendo tudo zoado, outro sistema que pega essa informação, eh, assim para deixar correto, mas que, tipo, que ele espera as coisas zoadas de um formato específico, né? Então, se é se o cara for lá e falar: "Não, agora vou ajustar esse sistema para outro formato que talvez seja menos zoado, mas aí agora a correção do sistema zoado não dá mais certo. Tem que ser,
Marcello Pontes: É tipo um overfit,
Deo Carlos: enfim,
Marcello Pontes: né? É tipo um overfit para um problema ruim.
Deo Carlos: é.
Marcello Pontes: Entendi. Ó,
Deo Carlos: S.
Marcello Pontes: deixa eu, deixa eu só dar minha visão do que que eu entendo sobre renegociação e vocês me levam para onde vocês estão. O que eu entendo renegociação, você tem um contrato e de parcelas, algumas dados baixa, outras você já tá perto de castigar, que você faz de cham renegocia, dá baixa no contrato antigo, gera um contrato novo, carrega eh, sei lá, o o o montante negociado pro pro contrato novo. Como é que como é que é aí? M.
Deo Carlos: Então,
Leonardo Sarmanho: Ja.

# 00:45:37

Deo Carlos: só só para falar isso de maneira mais sucinta possível, assim, tipo, o João, ele queria poder olhar pro contrato original e falar o que que o que que foi pago ou não foi pago desse contato original para conseguir ver isso de uma maneira entre aspas canônica. Então o como é que esse processo de renegociação foi implementado? Esse contrato original ele nunca morre. Aí existe virtualmente umas novas parcelas. Só que essas novas parcelas que são criadas e são pagas, elas são depois mapeadas para o contrato original e vão dando baixa no no contrato original de maneira parcial integral. Então existem n dificuldades e problemas em fazer isso e enfim e e muita coisa muito mais trivial é feito não muito correto. Quando você começa a colocar uma coisa um pouco mais complexa, pode esperar que o show de horror
Leonardo Sarmanho: É isso.
Deo Carlos: acontece.
Leonardo Sarmanho: E assim aí e até aí respondendo a sua pergunta, é quando acontece algumas renegociações, essas baixas em alguns casos ficam com eh aumenta a complexidade e a gente para rastrear isso e para corrigir isso é um pouco mais é um pouco mais complexo. Então,
Deo Carlos: M.
Leonardo Sarmanho: eu dei um exemplo de um problema simples de resolver, que é só basicamente reenviar o arquivo com o valor correto e essa um pouco mais difícil assim no sentido de reconstrução, de identificação do problema e assim por diante, como é hoje, tá?

# 00:47:08

Marcello Pontes: Entendi. Eh, tá. No caso de uma re negociação, se a gente pensa no nessa transação de informações que a gente tem com o fundo para administradora, ah, a gente não vai, a gente tem que dar baixa contábil, né, nisso daí, mas não pode dar baixa física ou ou como é, porque assim, o que que a gente pode fazer? Vamos lá, a gente tem um sistema novo que vai fazer em paralelo agora. O que a gente pode fazer é como a gente espera esse novo modelo de dados, eh, como a gente espera que ele se comporte, fazer isso e tem que fazer um depara do sistema antigo pro novo para poder fazer tradução simultânea do passado, pra gente sempre saber o que que tá acontecendo lá ver o que tá aqui, né? Eh, e aí quando a gente mandar abaixo, vai ser abaixo do contrato novo. A gente pode criar visão como se fosse um pai e filho, né? parent child de como o o não sei quem era o João que esperava ver isso, eh, que ele consiga ver isso como se fosse um e aí vai ser uma visão lógica, mas o contrato vai tá dado baixo, sendo que ele vai estar com status lá de de eh renegociado, né?

# 00:48:13

Marcello Pontes: Eh, então, enfim, a gente pode explorar esse tipo de alternativa, mas eh eventualmente a gente vai ter que fazer uma uma camada de tradução entre os
Deo Carlos: M.
Marcello Pontes: dois mundos e, enfim, no futuro, tratar isso daí.
Leonardo Sarmanho: É, eh, acho que assim, existe essa complexidade da renegociação e e eu não sei até que ponto talvez o D possa falar melhor se o pessoal de plataforma tá atacando esse problema ou não na raiz para fazer,
Deo Carlos: É, não chegaram lá,
Leonardo Sarmanho: Mais
Deo Carlos: mas não não chegaram nesse ponto ainda, né? são tão em tão em tão na parte de de de invoice e de pagamento no início e tal, mas na minha op na minha opinião assim eh pelo menos eu imaginaria que seria possível fazer algo nesse sentido de tipo, vamos pegar essa essas negociações e criar um dado derivado dele da forma como ele deveria ser de fato. E depois disso, tipo assim, as negociações que existem e é isso. Esqueça que isso para ser mapeado pelas parcelas originais. Existe negociações, tem assim, tal, não sei o quê. E depois a gente a gente define tipo qual seria essa forma de mapear essa parcela pro contrato original, seja pra gente fazer isso numa visão de crédito, seja para fazer isso, porque um problema de fazer esse tipo de modelagem assim é porque isso espirrou também como isso é feito junto a Milênia.

# 00:49:51

Deo Carlos: Então a a gente tem um feeling de que provavelmente não deve ser assim que a Milênio deve fazer em vários outros casos. deve ter um caso, o caso canônico deveria ser diferente disso, mas a hoje a gente nem parou para, enfim, analisar, investigar e entender exatamente, tipo, como essa questão de renegociação deveria ser feita sem ficar inventando
Leonardo Sarmanho: É, de fato, a gente não eh parou e e viu assim como seria a melhor forma. A gente chegou a ter umas conversas rápidas com eles, eles eles tem outras formas, eh outros lugares tratam esse problema de outras formas, mas a gente não chegou a ir no detalhe para saber essas outras formas, nem para, enfim, prospectar de uma forma melhor, né?
Deo Carlos: É, não, não fez isso porque, enfim, se fizesse fazer isso,
Marcello Pontes: Ja.
Deo Carlos: a única diferença que até a gente ia falar desse assunto de uma maneira mais mais conhecimento, mas não ia ter feito efeito nenhum porque, enfim, a gente não tá atacando isso agora, né? Então, mas o espírito, né, do que se tem, basicamente é isso.
Marcello Pontes: Eh, eu eu eu tendo a pensar disso numa forma de que se a gente tem numa estrutura de dados representados ali os grandes eventos e aí eu eu gosto de colocar evento evento contável, né, que tende a ser onde o pessoal se se baseia mais pra verdade.

# 00:51:16

Marcello Pontes: Aí você, por exemplo, ah, o contrato foi dado baixo nessa data e o motivo foi castigado, tá lá marcado pra história. Eh, o valor que foi dado baixa foi isso. E aí você pode ratear ao longo das passadas que estavam devos. O valor do desconto foi esse e aí rateia da maneira, enfim, tem uma uma acho que a própria rotina de renegociação deve ter isso daí para poder mostrar o que que vai, enfim, ou pelo menos poderia ter, né? a gente pode pensar nessa estrutura, mas se a gente tiver os grandes números, os grandes padrão parâmetros, né, da renovaciação, acho que o o que vem depois é formatar o dado ou o relatório da maneira como eh os entes diferentes esperam, seja seja eh crédito, seja contábel aí.
Leonardo Sarmanho: Eh, é isso. E então, em relação a esse esse ponto, eh, não sei se vocês têm mais alguma pergunta.
Marcello Pontes: Cara, eu tô eu tô por horas satisfeito pela explicação, eh, sabendo bastante coisas. Eu já sei que, por exemplo, não é só o dado, mas o próprio processo também de vocês dá para melhorar bastante. Eh, mas enfim, tem esse grande desafio do dado aí, né, que enfim, se a gente tem o dado correto, eu acho que o processo é questão de, enfim, é complexidade baixa para poder

# 00:52:40

Deo Carlos: É,
Marcello Pontes: melhorar.
Deo Carlos: existe um ponto aqui que não foi abordado aqui pelo Léo, eu vou colocar, mas que eu acho que tava lá no Notion também, eh, que o nosso processo interno também ele não salva todas as informações que ele deveria salvar. Então, existe algumas informações que são importantes para esse processo, é tipo a data que essa sessão efetivamente foi feita ou ele não salva. Talvez eu esteja falando de uma maneira muito eu acho que ele salva esse essa informação, mas em grande eh grande parte dos processos onde essa informação deveria ser utilizada, se usa outra data que é próxima dela, mas que nem sempre é ela e que dá valores incorretos também em alguns lugares, né? Então ter ter algumas informações, né? né? Tipo, quando com esse processo sendo conduzido na mão pelo pelo Léo, a gente vai começar a salvar algumas informações que a gente vai lidar com isso como fonte de verdade para esse processo de sessão e conciliação e que hoje em dia não tem pelo menos não esse nível de de confiabilidade, né? Então a gente vai gerar essa informação ali para ser a fonte da verdade, para saber, tipo, esse contrato foi cedido em tal data no valor de tal e, enfim, em algumas coisas específicas relacionadas com isso.
Leonardo Sarmanho: É,

# 00:53:58

Marcello Pontes: Beleza.
Leonardo Sarmanho: eu vou só mostrar uma última informação,
Marcello Pontes: M.
Leonardo Sarmanho: uma última último detalhe aqui só para agora para ficar um pouco mais claro assim. Чу. Vou mostrar aqui de uma forma bem assim, de novo, bem introdutória. Eu acho que a gente pode entrar mais no detalhe e também explicar um pouco melhor o que o que o Léo acabou de falar aqui. Vou, eu fiz uma query só para exemplificar um caso, um exemplo do, de como é feito hoje em dia, tá? Eh, no final, eh, a gente tem algumas tabelas eh no nosso no nosso eh nos nossos projetos aqui internos. Então, uma série de tabelas que a gente que a gente consulta para construir essas informações. Então, por exemplo, a gente pega a tabela de invoice, como eu falei, que é onde tem lá a primeira fonte da informação de pagamentos e etc. E aí a gente vai de fato fazendo alguns joins e a gente vai para construindo esse grande essa grande massa de dados, essa grande view aí no final das contas a gente vai eh beleza, eu vou aqui eu vou terminar rapidinho, tá Marcelo? Então, só para só para dar ainda um exemplo prático de como é feito de como é feito hoje,

# 00:56:20

Marcello Pontes: Tranquilo.
Leonardo Sarmanho: tá? Eh, então, eh, então a gente vai lá, pega a informação da tabela em voz, eh, faz alguns joys para pegar as informações, eh, as informações de parcelas, né, que são os installments. pega algumas outras informações que estão na estão registradas na tabela de contratos de propostas, como o número da CCB que tá tá aqui na tabela de de propostas e assim por diante para no final a gente construir aquele arquivo que eu falei eh que eu mostrei. Então, a gente pega o número da CCB como eu mostrei o o ID do contrato e etc, etc. Eu não vou entrar em cada detalhe aqui de informação, mas eh no final das contas eu a gente faz essa query, a gente eh vê a a as principais informações de quando foi pago, como foi pago, que eu quero dizer com isso, se foi em loja ou não foi em loja, eh quanto foi pago, que é a informação que hoje a gente pega da installments e não da invoices, que é o que seria o correto. e assim por diante pra gente construir e falar o seguinte:
Marcello Pontes: M.
Leonardo Sarmanho: "Olha, esse aqui essas essas informações, essa esses pagamentos foram feitos nesse nesses momentos e aí aí sim a gente consegue enviar pro pra gestora e nos informar".

# 00:57:49

Leonardo Sarmanho: Tem algumas, claro, algumas complexidades para construir esse arquivo do tipo, eu só tô mostrando uma query quando é feito, quando não é renegociação, que é quando a gente chama de parcela original, e quando é feito eh não é feito em loja. Aí tem a mesma quer quando é feito em loja, mesma quer quando é renegociação feito em loja e assim por diante. A gente faz alguns tratamentos desse dado do tipo,
Marcello Pontes: M.
Leonardo Sarmanho: ah, quando o pagamento é duplicado ou não, quando foi cancelado ou não foi cancelado, que é no caso de estorno, e assim por diante, a gente faz uma série de tratamentos via código, tá? Então, como eu falei, naquele pipeline spark lá, eh, hoje é via código, faz essa série de quereres, faz essa essas essas transformações no dado e aí sim a gente gera aquele arquivo, tá? Pode falar,
Marcello Pontes: Eh,
Leonardo Sarmanho: pode falar.
Marcello Pontes: quem é que mantém esse esse job no Spark? É, é você. Tem outra pessoa.
Leonardo Sarmanho: se desmantém no sentido de infra assim assim, a engenharia,
Marcello Pontes: Quem quem quem criou? Quem muda a
Leonardo Sarmanho: quem criou não tá mais aqui.

# 00:58:51

Leonardo Sarmanho: E assim, quem é o responsável sou eu,
Marcello Pontes: engenharia?
Leonardo Sarmanho: só que assim, eu não tenho tantas permissões assim no sentido de, por exemplo, um deploy eu preciso da engenharia, mas assim, eu que sou responsável por manter o código, tá?
Marcello Pontes: Uhum.
Leonardo Sarmanho: Então depois se você quiser também posso mostrar um pouco a cara dele e tá eh assim e e
Marcello Pontes: Так.
Leonardo Sarmanho: no final das contas assim é é um processo simples no sentido de construção de informação, só que essa construção de informação a gente precisa filtrar, precisa tratar, precisa transformar o dado para que a gente eh mande o valor correto e eh mantenha também internamente eh, colete as informações corretamente e armazene as informações corretas, coisa que hoje é um grande problema do processo, tá? Eh, acho que é isso que o que eu queria mostrar, Marcelo. Assim, de novo, acho que se você quiser, a gente pode entrar ainda mais. Eu vou te mostrar ainda mais detalhes, mas eu não sei até que ponto você quer deixar para hoje, para outro dia.
Marcello Pontes: Cara, eh, deixa eu ver aqui. Desculpa que o Bruno tá mandando mensagem aqui, mas eu vou, deixa eu finalizar contigo aqui.

# 01:00:09

Marcello Pontes: Pô, obrigado pela tua informação. Se tu puder, eh, se tu tiver como, manda para mim. Não sei se tu tem acesso ao código desse job do PAP Par que acho que seria de grande valor para eu entender muita coisa agora, mas de antemão, p****, já deu bastante informação aí, eu acho que já me ajudou bastante. Eh, eu vou eu vou eu vou ter que correr atrás das informações, né,
Leonardo Sarmanho: Tá,
Marcello Pontes: do Job do PA Park, tipo, criar um outro outro negócio paralelo para poder a gente ajudar a validar os dados, tá? Para ver se tá correto. E aí tu vai me ajudar com isso daí.
Leonardo Sarmanho: tá? Então vou já vou te mandar aqui agora. Você tem acesso aos eh ao aos repositórios aqui, né, internos.
Marcello Pontes: Hum, provavelmente não. Me dá o nome desse repositório ou dos repositórios que tu acha que são relevantes. Se tu puder me passar lá no SL. Tu tá no Slack lá do Data P. Deixa eu ver aqui. Acho que tá, né?
Leonardo Sarmanho: Acho que
Marcello Pontes: Shoho. Ô, ó.

# 01:01:03

Marcello Pontes: Tá, mano.
Leonardo Sarmanho: não.
Marcello Pontes: Deixa eu te chamar aqui. Deixa eu pedir pro eh, rapidão, rapidão. Desculpa me dar só um segundo aqui. Deixa eu ver aqui.
Leonardo Sarmanho: Tranquilo, tranquilo.
Marcello Pontes: Ah, tá. Ah, não. Beleza, beleza, beleza. Vou, eu vou terminar depois aqui. Eh, beleza. Tá. Então é isso, só se tu puder só mandar a lista. Pode mandar pro Léo Luiz ou pro Wagner ou pro Bruno. Eu pedi de todo jeito. Eu pedi pro Del e pro Bruno para ver se pode te adicionar lá nos leques do pra gente começar a bater bola mais rápido, sabe?
Leonardo Sarmanho: É, mas eu não tô te encontrando no Slack para eu já tentar te enviar.
Marcello Pontes: vai ajudar bastante. Ih, cara,
Leonardo Sarmanho: Tá.
Marcello Pontes: eh, ih, é complicado. Pão, então manda por e-mail, manda nesse e-mail aqui. Deixa eu. Tu tem esse e-mail aqui, meu?

# 01:02:03

Leonardo Sarmanho: É porque nem eu procuro aqui porque eu vi pelo coisa
Marcello Pontes: Pera aí que eu acho aqui rapidinho,
Leonardo Sarmanho: do Ah,
Marcello Pontes: cara. Rapid zero bron.
Leonardo Sarmanho: tá. Tenho agora.
Marcello Pontes: Boa. Tem esse aqui, ó. Não sei se é esse mesmo que tu tem. Tem um, tem vários e-mail aí. Esse daume aí é o que é o oficial.
Leonardo Sarmanho: É isso. Senhor, foi esse aqui, não. Beleza, Marcelo. Então, vou tentar detalhar um pouco assim o o job que é o Park, o eh talvez mandar um arquivo, se você quiser, coisas desse tipo.
Marcello Pontes: ajuda, ajuda alguma coisa também,
Leonardo Sarmanho: Aí,
Marcello Pontes: se tu puder do do web hook de retorno também ajuda.
Leonardo Sarmanho: tá,
Marcello Pontes: Да.
Leonardo Sarmanho: eu vou te mandar uma documentação deles. E o, é porque eu não, o web é um sistema que é esse é mantido assim bastante pela engenharia. Eu já não tenho tanto tanto acesso não.
Marcello Pontes: Entendi. Beleza. Não, seria só um snipet uma não vez, não sei se consegue pegar um corpo de Jon daquele lá que vem só para ter uma dar uma olhada só para contexto
Leonardo Sarmanho: Ja.
Marcello Pontes: mesmo. Aí se tu puder tu, enfim, não sei qual é a melhor maneira que eu gostaria de compartilhar, mas por exemplo uma pastazinha no drive com esses recursos lá e acho que ficaria fácil para todo mundo. Pô, obrigado, Léo.