F
Finblue/Status de Implantação
Voltar
Atualizado em 10 de maio de 2026

Roadmap & Progresso

Acompanhamento transparente do que já foi entregue, o que está em desenvolvimento e o que ainda virá no Finblue.

Progresso geral
45%
40 de 88 itens concluídos
Fases concluídas
1 / 14
100% dos itens entregues
Em andamento
5
F1 — Fundação (Design System + Layout) ✅ · F2 — Autenticação + Multiempresa ✅ (parcial) · F3 — RBAC (Perfis e Permissões) ✅ (parcial) · F5 — Contas a Pagar ✅ (parcial) · F6 — Contas a Receber ✅ (parcial)
Implantação total45%

Fases

Fase 1 — Fundação (Design System + Layout)
Em andamento
5/6
  • Design system Navy Trust em src/styles.css (tokens oklch, dark mode)
  • Tipografia Sora (headings) + Manrope (body)
  • Layout base: sidebar recolhível + topbar + área de conteúdo
  • Toggle dark/light mode
  • Landing/login pública vs área autenticada _authenticated/
  • Componentes UI base (Card, DataTable, StatCard, PageHeader) — parcial: Card ok; faltam DataTable, StatCard e PageHeader reutilizáveis
Fase 2 — Autenticação + Multiempresa
Em andamento
9/10
  • Habilitar Lovable Cloud
  • Tabela companies (empresas/tenants)
  • Tabela profiles (vínculo com auth.users)
  • Tabela company_members (usuário ↔ empresa, N:N)
  • Login email/senha
  • Login com Google → movido para Backlog
  • Recuperação de senha (/forgot-password + /reset-password)
  • Seletor de empresa ativa (context global)
  • RLS em todas as tabelas com filtro por company_id
  • Guard _authenticated/ + redirect
Fase 3 — RBAC (Perfis e Permissões)
Em andamento
6/7
  • Enum app_role: super_admin, admin, financeiro, gestor, usuario, auditor (criado na Fase 2)
  • Tabela user_roles (user_id, company_id, role) (criada na Fase 2)
  • Function has_role() security definer (criada na Fase 2)
  • Matriz de permissões por módulo/ação (src/lib/permissions.ts)
  • Hook usePermission() no frontend (can, isAdmin, isSuperAdmin)
  • CRUD de usuários: convidar (e-mail), trocar papel, ativar/desativar, redefinir senha, remover da empresa (/app/usuarios)
  • Function SQL has_permission(module, action) → movido para Backlog (matriz vive no frontend; só vale puxar pro DB quando precisarmos validar permissões em policies de tabelas de domínio)
Fase 4 — Cadastros Auxiliares
Concluída
9/9
  • Fornecedores (/app/fornecedores)
  • Clientes (/app/clientes)
  • Categorias financeiras (/app/categorias) — hierárquica, separada por receita/despesa, validação de ciclo no DB
  • Centros de custo (/app/centros-custo) — código único por empresa
  • Contas bancárias (/app/contas-bancarias) — tipo, banco, agência/conta, saldo inicial
  • Componente ResourceCrud reutilizável (src/components/resource-crud.tsx)
  • RLS: leitura para membros; escrita só para admin/financeiro (can_manage_registry)
  • Soft delete (deleted_at) em todos os cadastros
  • Sidebar com grupo "Cadastros" + grupo "Administração" oculto para não-admin
Fase 5 — Contas a Pagar
Em andamento
6/10
  • CRUD de despesas (fornecedor, categoria, centro de custo, conta bancária, vencimento)
  • Parcelamento (gera N parcelas mensais a partir do 1º vencimento)
  • Status: pendente / aprovado / pago / vencido (auto) / cancelado
  • Aprovação (perfil gestor ou admin)
  • Baixa financeira (data + valor pago)
  • Filtros (busca + status) e cards de totais (em aberto / vencido / pago no mês)
  • Recorrência → Backlog
  • Upload de anexos (Storage) → Backlog
  • Exportação PDF / Excel / CSV → Backlog
  • Fluxo de aprovação multi-etapa → Backlog
Fase 6 — Contas a Receber
Em andamento
5/9
  • CRUD de receitas (cliente, categoria, centro de custo, conta bancária, vencimento)
  • Parcelamento mensal
  • Status: pendente / recebido / atrasado (auto) / cancelado
  • Baixa de recebimento (data + valor)
  • Filtros + cards (em aberto / atrasado / recebido no mês)
  • Emissão de cobrança / boleto → Backlog
  • Recorrência → Backlog
  • Anexos → Backlog
  • Exportação → Backlog
Fase 7 — Empenhos
Planejada
0/4
  • CRUD: número, órgão, fornecedor, valor, saldo
  • Fluxo: emissão → liquidação → pagamento (parcial/total) → cancelamento
  • Histórico de movimentações
  • Anexos
Fase 8 — Fluxo de Caixa
Planejada
0/5
  • Consolidação entradas/saídas
  • Saldo diário e mensal
  • Previsão financeira (baseada em CP/CR pendentes)
  • Gráficos
  • DRE simplificado
Fase 8.5 — Conciliação Bancária
Planejada
0/6
  • Importação de extrato bancário (OFX / CSV) por conta bancária
  • Tela de conciliação: extrato × lançamentos do sistema (match manual e sugerido)
  • Marcar lançamentos como conciliados (status + data de conciliação)
  • Criar lançamento avulso a partir de linha do extrato não identificada
  • Desfazer conciliação
  • Relatório de divergências e saldo conciliado por período
Fase 9 — Dashboard Executivo
Planejada
0/5
  • Cards: CP do mês, CR do mês, saldo, inadimplência
  • Gráfico fluxo de caixa
  • Despesas por categoria (pizza)
  • Receitas (barras)
  • Alertas e indicadores
Fase 10 — Relatórios
Planejada
0/7
  • Relatório financeiro consolidado
  • Fluxo de caixa
  • Despesas / Receitas / Empenhos
  • Inadimplência
  • Por centro de custo
  • Auditoria
  • Export PDF / Excel / CSV
Fase 11 — Auditoria
Planejada
0/3
  • Tabela audit_logs (user, action, entity, before/after, ip, timestamp)
  • Trigger automático nas tabelas críticas
  • Tela de consulta com filtros
Fase 12 — Notificações
Planejada
0/3
  • Tabela notifications + painel interno (sino no topbar)
  • Triggers: vencimento próximo, conta atrasada, aprovação pendente
  • Envio por e-mail (edge function ou server fn)
Fase 13 — Extras / Polimento
Planejada
0/4
  • Pesquisa global (Cmd+K)
  • Histórico de alterações por registro
  • Ajustes finos de UX
  • Documentação interna

Backlog

Melhorias e débitos técnicos identificados ao longo do desenvolvimento, agendados para entregas futuras.

  • Login com Google (OAuth) — habilitar Sign-in with Google via Lovable Cloud Managed OAuth na tela de login/cadastro (botão "Entrar com Google"), além do email/senha já existente.
  • has_permission(module, action) em SQL — replicar a matriz de src/lib/permissions.ts como função SECURITY DEFINER no Postgres para usar dentro de RLS policies das próximas tabelas (despesas, receitas, empenhos…).
  • Página /app/empresas — CRUD de empresas (apenas super_admin). Hoje só existe a criação via onboarding.
  • Páginas /app/auditoria e /app/configuracoes — links removidos do sidebar até existirem (Fase 11 / Fase 13).
  • Inativar categoria via UI — hoje a tela de categorias só edita/exclui; falta toggle de is_active (campo já existe no DB).
  • Endereço completo nos cadastros — formulário simplificado; falta máscara de CEP, autocompletar via ViaCEP e validação de CNPJ/CPF.
  • Linter Supabase: 4 warnings persistentes (SECURITY DEFINER chamáveis por authenticated) — necessários para que as RLS policies funcionem; aceitos como falso-positivo do linter.
  • CP/CR — Recorrência (Fase 5/6) — gerar lançamentos repetitivos automáticos (mensal/quinzenal/anual).
  • CP/CR — Anexos (Fase 5/6) — upload de notas fiscais e comprovantes via Storage.
  • CP/CR — Exportação (Fase 5/6) — PDF/Excel/CSV das listagens.
  • CP — Aprovação multi-etapa (Fase 5) — fluxo configurável de aprovadores com histórico.
  • CR — Emissão de cobrança/boleto (Fase 6) — integração com gateway de pagamento.
  • Job de auto-vencido — cron diário para mover lançamentos pendente/aprovado com vencimento passado para vencido/atrasado direto no banco (hoje é calculado só no client-side).