Estado atual
O Receiva é usado diariamente por três pessoas na GoldCash, uma operação familiar de crédito. Eu o construí e também trabalho dentro dessa operação. A certificação formal de produção está em andamento.
A Fomentis continua sendo a fonte de verdade financeira. O Receiva importa os exports dela (XLSX/CSV) e acrescenta o que a operação precisava ao redor deles: uma posição de carteira reconciliada, faixas de atraso e o acompanhamento da cobrança — contatos, negociações, promessas de pagamento, notificações, processos e próximas ações. Ele não escreve de volta na Fomentis e não a substitui.
A posição de origem analisada para a primeira versão tinha cerca de 2 mil títulos.
O problema
Os dados já existiam. Uma visão deles em que a operação pudesse confiar, não. Exports periódicos chegam de fontes de naturezas diferentes — incluindo evidência reconstruída à mão — e transformá-los em "o que existe, o que venceu e quem precisa de atenção hoje" era trabalho manual e difícil de conferir.
Decisões
- Uma camada, não um substituto. O sistema financeiro continua sendo a autoridade; o Receiva lê os exports e nunca o altera. Ver ADR-0001.
- Dado importado não é editável. Linhas de origem aceitas são protegidas contra alteração e exclusão no nível do banco de dados. O estado operacional do Receiva fica em tabelas separadas, ligado por identidades de origem com namespace, e não por chaves estrangeiras para as linhas importadas.
- Todo número mantém sua origem. Os valores continuam ligados ao arquivo, ao período, à linha e ao lote de importação.
- A leitura segue a posição publicada, não o último upload. Um novo import só vira a visão atual quando uma posição coerente e reconciliada é publicada.
- Fontes diferentes continuam diferentes. Exports oficiais e evidência reconstruída à mão passam por caminhos separados de leitura e reconciliação, em vez de serem somados.
- Estado de cobrança que não se desalinha. Uma promessa pendente com data vencida aparece como quebrada no momento da leitura, sem job agendado. Publicar nova exposição vencida reabre automaticamente um cliente que estava marcado como resolvido.
- Performance fazendo menos trabalho. As leituras da carteira deixaram de buscar arquivos de origem armazenados e colunas não usadas, e uma consulta que rodava três vezes na página da carteira passou a rodar uma vez (quatro idas ao banco viraram duas), com testes de equivalência. Tempos só serão publicados depois de um benchmark reproduzível.
Limites conhecidos
- O acesso é compartilhado: as três pessoas que usam o Receiva entram com a mesma credencial de administrador. Mudanças de estado são registradas com valores de antes e depois, mas não são atribuídas a pessoas específicas. Identidade individual está planejada.
- Não há controle de acesso por papel. As visões executiva e operacional são telas diferentes, não permissões diferentes.
- O trabalho de cobrança é ordenado por níveis operacionais explícitos, não por um modelo de score.
- O fechamento diário é registrado manualmente. Abrir uma conversa de WhatsApp pela interface não gera registro automático; os contatos são registrados explicitamente.
- Nenhum ganho de produtividade ou resultado financeiro é afirmado; nenhum foi medido formalmente.
Discovery, não capacidade
A UNICAR é a primeira operação externa em discovery. Um modo nativo separado (RECEIVA_NATIVE) e adaptadores por operação são trabalho de arquitetura, não capacidades implementadas. Generalizar vem depois da evidência, não antes — ver Por que recusei generalizar um sistema financeiro que funciona.
A página pública do Receiva usa apenas dados fictícios.