scoreodonto.com/documentação/MAPA-FUNCIONAL-COMPLETO.md

MAPA FUNCIONAL COMPLETO — ScoreOdonto

Auditoria funcional baseada SOMENTE em evidências do código. Nada aqui foi assumido. Fonte: frontend/ (React 19 + Vite, roteador próprio em App.tsx) e backend/server.js (Express monolítico, ~516 KB, 277 rotas, ~70 tabelas Postgres acessadas por SQL direto). Estado verificado: produção v1.0.18 · DEV dev (banco isolado pgdev). Data: 19/jun/2026.

---

Sumário executivo (o que o sistema É, na prática)

O ScoreOdonto é um ERP odontológico multiempresa (SaaS) cujo núcleo é o ciclo Lead → Paciente → Agenda → Procedimento → Financeiro → Comissão → Repasse, com módulos clínicos (Ortodontia, Próteses/GTO, RX), administrativos (Equipe/RBAC, Planos, Procedimentos) e três frentes de marketplace (Locação de Salas, Diretório/Propostas de Profissionais, Tutoria de Ortodontia — esta última a única com cobrança automatizada via MercadoPago).

A arquitetura é multi-tenant real: quase toda rota passa por tenantGuard e filtra por clinica_id. O "workspace" ativo (clínica ou sala) governa menu, permissões e dados visíveis.

Evidências estruturais:

• Frontend sem react-router: roteamento próprio (ROUTE_MAP / VIEW_TO_ROUTE em App.tsx).
• 44 views (frontend/views/*.tsx), 16 componentes, 3 plugins.
• Backend num único server.js (516 KB) — sem camada de serviços/controllers separada.
• Prisma quase não usado (4 modelos legados de GTO); o banco real é SQL puro via pg.

---

ETAPA 1 — INVENTÁRIO DE ROTAS

Roteamento definido em frontend/App.tsx (ROUTE_MAP, VIEW_TO_ROUTE, renderView, isViewAllowed). Papéis (roles): superadmin, admin, donoclinica, donoconsultorio, funcionario, dentista, biomedico, protetico, paciente, donosala. Tipos de workspace: clínica (padrão) e sala (isola o contexto). Plugins: rx-scoreodonto, locacao-salas (sempre ON), profissionais-marketplace.

URL	View	Componente / Arquivo	Acesso (papéis)	Origem	Destino
/	landing	LandingPage.tsx	Público	—	login / área
/login	login	LoginView.tsx	Público	landing	dashboard por papel
/contato	public	PublicContactForm.tsx	Público	landing	cria interesse/lead
/dashboard	dashboard	Dashboard.tsx	admin/donos/func/dentista/bio/prot	login, menu	agenda, pacientes
/leads	leads	LeadsView.tsx	admin/donos/funcionário	menu	converter→paciente+agenda
/pacientes	pacientes	PatientsView.tsx	admin/donos/funcionário	menu, dashboard	agenda, orçamento, procedimento, ortodontia, RX
/agenda	agenda	AgendaView.tsx	quase todos os papéis clínicos	menu, dashboard	paciente, avaliação, procedimento
/ortodontia	ortodontia	OrthoView.tsx	dentista (odonto)	menu, paciente	evolução, fotos, tutoria
/financeiro	financeiro	FinanceiroView.tsx	admin/donos/funcionário	menu	comissão, glosa
/comissoes	comissoes	ComissoesView.tsx	admin/donos	menu apenas ⚠️	repasse
/glosas	glosas	GlosasView.tsx	admin/donos/funcionário	menu apenas ⚠️	recebíveis convênio
/proteses	proteses	ProteseView.tsx	dentista/protético/func	menu	OS de laboratório, GTO
/orcamentos	orcamentos	OrcamentosView.tsx	admin/donos/funcionário	menu, paciente	contrato
/contratos	contratos	ContratosView.tsx	admin/donos/funcionário	menu, orçamento	cobrança/financeiro
/relatorios	relatorios	ReportsView.tsx	admin/donos/funcionário	menu	—
/tratamentos	tratamentos	MeusTratamentos.tsx	paciente + clínicos	menu	—
/lancar-gto	lancar-gto	LancarGTO.tsx	biomédico/protético/func	menu	guias odontológicas
/notificacoes	notificacoes	NotificationsView.tsx	todos	menu	—
/clinicas	clinicas	ClinicasView.tsx	membros	menu, seletor de workspace	criar-clinica
/gestao-equipe	gestao-equipe	GestaoEquipeView.tsx	admin/donos	menu	membros, cargos (RBAC)
/admin/dentistas	dentistas	AdminViews.tsx	admin/donos	menu	horários
/admin/especialidades	especialidades	AdminViews.tsx	admin/donos/biomédico	menu	procedimentos
/admin/procedimentos	procedimentos	AdminViews.tsx	admin/donos/biomédico	menu	valores por plano
/admin/planos	planos	AdminViews.tsx	admin/donos	menu	—
/admin/sync	sync	AdminViews.tsx (SyncView)	NINGUÉM (bloqueado) ⚠️	—	—
/plugins	plugins	PluginsView.tsx	superadmin apenas	menu (superadmin)	ativa plugins
/rx-radiografias	rx-radiografias	plugins/RXPlugin.tsx	dentista/donos/func (plugin RX)	menu	dispositivos RX
/rx-config	rx-config	RxConfigView.tsx	admin/donos/superadmin	menu	dispositivos RX
/salas /minhas-salas /alugar-salas	salas	plugins/SalasPlugin.tsx	todos (plugin locacao-salas, sempre ON)	menu	reservas
/sala-home	sala-home	SalaHomeView.tsx	workspace tipo sala	seletor de workspace	reservas da sala
/marketplace-profissionais	marketplace-profissionais	plugins/ProfissionaisPlugin.tsx	clínicos exceto paciente (plugin)	menu	propostas
/diretorio-profissionais	diretorio-profissionais	DiretorioProfissionaisView.tsx (absorvido pelo plugin)	clínicos	menu	—
/candidatura-tutor	candidatura-tutor	TutorCandidaturaView.tsx	dentista	menu	pagamento MercadoPago
/tutoria-painel	tutoria-painel	TutorPainelView.tsx	tutores aprovados (is_tutor)	menu	solicitações
/admin-gestao-tutores	admin-gestao-tutores	AdminGestaoTutoresView.tsx	superadmin	menu	confirma pagamentos/repasses
/criar-clinica	criar-clinica	CreateClinicView.tsx	admin/donos sem workspace	pós-cadastro	dashboard
/cadastro-dentista	cadastro-dentista	DentistRegisterView.tsx	standalone (magic-link)	menu apenas ⚠️	aguardando-convite
/aguardando-convite	aguardando-convite	WaitingInviteView.tsx	dentista/bio/prot sem vínculo	pós-cadastro	—
/superadmin/*	superadmin-*	SuperAdminView.tsx (tabs)	superadmin	menu	usuários, clínicas, logs, financeiro, notificações
/update	update	UpdateDbView.tsx	técnica (URL direta, sempre liberada)	fora do menu	migração de banco

⚠️ Inconsistências de roteamento encontradas (evidência: ROUTE_MAP vs VIEW_TO_ROUTE em App.tsx):

• /comissoes, /glosas e /cadastro-dentista existem em VIEW_TO_ROUTE (a navegação por menu empurra a URL), mas NÃO existem em ROUTE_MAP. Consequência: abrir essas URLs direto (deep-link / refresh) cai em dashboard. Deep-link quebrado para 3 telas reais.
• /admin/sync está mapeada, mas isViewAllowed retorna false sempre (substituída por "backup por clínica"). A tela e a rota existem, porém são inacessíveis (código morto navegável).

---

ETAPA 2 — INVENTÁRIO DE TELAS

(Resumo por tela — objetivo / usuário-alvo / valor / dependências / impacto. Apenas telas reais.)

Dashboard

• Objetivo: visão consolidada (KPIs via GET /api/dashboard/stats). Usuário: gestores/clínicos.
• Valor: ponto de entrada operacional. Depende de: agenda, pacientes, financeiro. Impacta: navegação.

Leads / Gestão de Leads

• Objetivo: captar e converter interessados em pacientes. Usuário: funcionário/donos.
• Valor: topo do funil comercial. Depende de: interesses/contato público. Impacta: Pacientes + Agenda (a conversão cria ambos — POST /api/leads/:id/converter).

Pacientes

• Objetivo: prontuário e cadastro (dados, família, score, faltas). Usuário: funcionário/donos.
• Valor: entidade central do negócio. Depende de: clínica ativa. Impacta: Agenda, Orçamento, Procedimento realizado, Ortodontia, RX, Receita/Exame. É o hub clínico (view de 92 KB).

Agenda

• Objetivo: agendar/confirmar/remarcar; controle de presença e anti-overbooking. Usuário: todos clínicos.
• Valor: coração operacional. Depende de: Pacientes, Dentistas+horários. Impacta: Avaliação, Procedimento, Financeiro (presença libera lançamento).

Ortodontia

• Objetivo: tratamento orto completo (triagem, diagnóstico, plano, evoluções, fotos, contenção). Usuário: dentista.
• Valor: vertical clínica de alto valor recorrente. Depende de: Paciente. Impacta: Tutoria, fotos.

Próteses / GTO

• Objetivo: OS de laboratório (protese_os), produtos, custo lab, entrega. Usuário: protético/dentista.
• Valor: controle do laboratório e do custo que abate comissão. Depende de: Procedimentos, Laboratórios. Impacta: Comissão (custo lab entra no cálculo).

Financeiro

• Objetivo: contas a receber/pagar (financeiro: RECEITA/DESPESA), formas, centro de custo, fornecedor. Usuário: gestores.
• Valor: caixa da clínica. Depende de: Procedimentos realizados, Contratos, Repasses. Impacta: Comissão, Glosa.

Comissões

• Objetivo: definir % (padrão da clínica, por procedimento, override por profissional) e ver produção/comissão.
• Usuário: donos. Depende de: Procedimentos realizados + Próteses (custo lab). Impacta: Repasses.

Glosas

• Objetivo: registrar glosa sobre recebíveis (convênio), recorrer, recuperar. Usuário: gestores.
• Valor: recupera receita negada por convênio. Depende de: Financeiro (recebíveis). Impacta: caixa.

Orçamentos → Contratos

• Objetivo: propor tratamento (itens/valores) e formalizar em contrato (modelos com variáveis, assinatura, cobrança).
• Usuário: funcionário/donos. Depende de: Paciente, Procedimentos. Impacta: Financeiro (gerar-cobranca).

Equipe / Usuários (RBAC)

• Objetivo: membros, cargos (funcoes), setores e permissões por workspace. Usuário: donos.
• Valor: governa quem vê o quê. Impacta: menu e isViewAllowed de todos os membros.

Salas (Locação) / Painel da Sala

• Objetivo: cadastrar salas, publicar no marketplace, receber/aceitar reservas. Usuário: qualquer conta.
• Valor: receita de locação P2P. Depende de: conta/sala. Impacta: sala_reservas.

Marketplace de Profissionais / Diretório

• Objetivo: profissional publica perfil; clínica envia proposta (propostas_profissional). Usuário: clínicas e profissionais.
• Valor: conexão oferta/demanda de mão de obra. Impacta: mensagens/propostas (sem cobrança hoje).

Tutoria de Ortodontia (Candidatura / Painel / Gestão)

• Objetivo: dentista vira tutor (pagando inscrição via MercadoPago); resolve solicitações orto.
• Usuário: dentistas + superadmin (gestão). Valor: única receita de plataforma automatizada.

SuperAdmin (overview/users/clínicas/logs/financeiro/notificações)

• Objetivo: administração global da plataforma (preços/assinaturas, broadcast, auditoria de acesso).
• Usuário: superadmin. Valor: operação do SaaS.

Configurações / Notificações / Minhas Clínicas

• Conta, integrações (Google), backup por clínica; notificações; seletor/gestão de workspaces.

---

ETAPA 3 — INVENTÁRIO DE BOTÕES (telas transacionais)

Rótulos extraídos das views; ações mapeadas para as rotas/tabelas do backend.

Agenda (AgendaView.tsx)

• Novo Agendamento → POST /api/agendamentos → tabela agendamentos. Fluxo: Paciente ↓ Procedimento ↓ Financeiro.
• Confirmar / Confirmar Presença → POST /api/agendamentos/:id/confirmar + /api/agenda/presenca → agendamentos, agenda_presenca. Libera lançamento financeiro.
• Reagendar / Remarcar → POST /api/agendamentos/:id/remarcar → agendamentos.
• Registrar Falta → POST /api/agendamentos/:id/falta → agendamentos (impacta score do paciente).
• Solicitar Avaliação → POST /api/agendamentos/:id/solicitar-avaliacao → avaliacoes.

Pacientes (PatientsView.tsx)

• Editar/Cadastrar Paciente → POST|PUT /api/pacientes → pacientes.
• Agendar → abre fluxo da Agenda. Lançar Procedimento (LancarProcedimentoModal) → POST /api/procedimentos-realizados → procedimentos_realizados (+ gera financeiro).
• Orçamento (OrcamentoModal) → orcamentos. Receita (ReceitaModal) → modelos_receita/items_receita. Pedido de Exame (PedidoExameModal) → pedidos_exame.

Financeiro (FinanceiroView.tsx)

• Novo lançamento (RECEITA/DESPESA, forma, vencimento, centro de custo, fornecedor) → POST /api/financeiro → financeiro.
• Marcar Pago / Alterar / Excluir → PUT|DELETE /api/financeiro/:id → financeiro.

Comissões (ComissoesView.tsx)

• Salvar % padrão / por procedimento / override por profissional → PUT /api/comissoes/regras → comissao_regras.
• Base de cálculo (produção × recebido) e Custo lab abatido. Próximo fluxo: Fechar repasse.

Repasses (em Financeiro/Comissões)

• Fechar Repasse → POST /api/repasses/fechar → repasses (status fechado).
• Pagar → POST /api/repasses/:id/pagar → cria DESPESA em financeiro (origem repasse, centro de custo COMISSÕES).
• Anexar Comprovante → POST /api/repasses/:id/comprovante. Cancelar → estorna a despesa.

Glosas (GlosasView.tsx)

• Registrar Glosa (total/livre, motivo, valor) → POST /api/glosas → glosas.
• Recorrer → POST /api/glosas/:id/recorrer. Recuperar → POST /api/glosas/:id/recuperar.

Orçamentos / Contratos

• Novo Orçamento (itens, valor, entrada, parcelas) → POST /api/orcamentos → orcamentos/orcamento_itens.
• Gerar Contrato (modelo + variáveis + prévia) → POST /api/contratos/instancias → contratos.
• Enviar / Assinar / Gerar Cobrança / Cancelar → POST /api/contratos/instancias/:id/{enviar,assinar,gerar-cobranca,cancelar} → liga ao financeiro.

Próteses (ProteseView.tsx)

• Nova OS (produto, dentes, material, custo lab, preço, prazo) → POST /api/protese/os → protese_os.
• Marcar Entregue / Mudar Status → POST /api/protese/os/:id/status → protese_os_evento.

Leads (LeadsView.tsx)

• Cadastrar Lead → POST /api/leads → leads.
• Cadastrar o Paciente / Converter (com data, hora, dentista) → POST /api/leads/:id/converter → cria pacientes + agendamentos (anti-overbooking).

---

ETAPA 4 — FLUXOS DE NEGÓCIO

Fluxo principal (núcleo do produto) — COMPLETO

Lead/Interesse ──converter──▶ Paciente ──▶ Agenda ──confirmar/presença──▶ Atendimento
   (leads)                   (pacientes)  (agendamentos)                      │
                                                                              ▼
                                                            Procedimento Realizado
                                                            (procedimentos_realizados)
                                                                              │ valor>0
                                                                              ▼
                                                   Financeiro RECEITA (origem='procedimento')
                                                            (financeiro, flag sem_comissao)
                                                                              │
                                          computeComissoes = (base − custo_lab) × %
                                                                              ▼
                                              Repasse FECHADO (repasses) ──pagar──▶
                                              Financeiro DESPESA (origem='repasse',
                                                       centro_custo='COMISSÕES')

• Onde começa: Lead/Interesse (ou cadastro direto de Paciente).
• Onde termina: pagamento do repasse ao profissional (DESPESA conciliada no caixa) — ciclo fechado.
• Onde quebra / desvio:
  • Geração de RECEITA é opcional (gerarLancamento !== false e valor>0): um procedimento sem valor não entra no financeiro — possível receita não registrada (depende do operador).
  • Glosa é um ramo paralelo sobre recebíveis de convênio (recupera receita), não integrado ao repasse.
  • Garantia/Reabertura marcam sem_comissao (regra: garantia sempre; reabertura só se mesmo profissional) — corretamente excluídas do repasse.
• Duplicidade: não há dupla geração de comissão — o repasse pago entra como DESPESA com sem_comissao=true (evita recomissionar). Bom controle.

Fluxo comercial paralelo

Orçamento (orcamentos) ──▶ Contrato (contratos) ──gerar-cobranca──▶ Financeiro (a receber)

Fluxos de marketplace (ver Etapas 7 e 8)

Sala (salas) ──publica──▶ Marketplace ──reserva──▶ sala_reservas (valor, status) [pagamento MANUAL]
Profissional ──perfil──▶ Diretório ──proposta──▶ propostas_profissional (mensagem) [sem cobrança]
Dentista ──candidatura──▶ MercadoPago (pago) ──webhook──▶ Tutor ativo ──▶ Solicitações de tutoria

---

ETAPA 5 — MATRIZ DE MÓDULOS

Módulo	Existe?	Acessível?	Funcional?	Completo?	Em uso?	Classificação
Autenticação / Workspaces / RBAC	Sim	Sim	Sim	Sim	Sim	Maduro
Pacientes	Sim	Sim	Sim	Sim	Sim	Maduro
Agenda (+presença/anti-overbooking)	Sim	Sim	Sim	Sim	Sim	Maduro
Financeiro (receita/despesa)	Sim	Sim	Sim	Sim	Sim	Maduro
Comissão + Repasse	Sim	Sim	Sim	Sim	Sim	Operacional
Glosas	Sim	menu apenas (deep-link quebrado)	Sim	Parcial	Sim	Operacional
Orçamentos → Contratos	Sim	Sim	Sim	Sim	Sim	Operacional
Ortodontia	Sim	Sim	Sim	Sim	Sim	Maduro
Próteses / GTO	Sim	Sim	Sim	Parcial	Sim	Operacional
Leads	Sim	Sim	Sim	Sim	Sim	Operacional
Plano/Procedimentos/Especialidades	Sim	Sim	Sim	Sim	Sim	Operacional
RX / Radiografias (plugin)	Sim	por plugin/papel	Sim	Parcial	depende clínica	Parcial
Locação de Salas (marketplace)	Sim	Sim (sempre ON)	Sim	Parcial (sem gateway)	baixo	Parcial
Marketplace Profissionais	Sim	por plugin	Sim	Parcial (só mensagem)	baixo	MVP
Tutoria de Ortodontia (MercadoPago)	Sim	Sim	Sim	Sim	baixo	Operacional
SuperAdmin	Sim	superadmin	Sim	Sim	Sim	Operacional
Sync Google/legado (global)	Sim	bloqueado	parcial	—	não	Abandonado
Relatórios	Sim	Sim	Sim	Parcial	Sim	Parcial

---

ETAPA 6 — MULTIEMPRESA

Evidência: quase todas as 277 rotas usam tenantGuard e filtram por req.clinicaId/clinica_id. O workspace ativo é resolvido por GET /api/me/workspaces (tabela vinculos = usuário↔clínica) + salas próprias.

Entidade	Como é modelada	Multiempresa respeitado?
Workspaces	vinculos (clínica) + salas (tipo sala); seletor no Sidebar	✅ Sim
Clínicas	clinicas + clinica_id em todas as tabelas operacionais	✅ Sim
Consultórios	papel donoconsultorio (variação de dono, mesmo modelo de clínica)	✅ Sim
Dentistas / Biomédicos / Protéticos	papéis distintos com menus próprios; vínculo por clínica	✅ Sim
Salas	salas + workspace tipo='sala' isola o contexto (menu reduzido)	✅ Sim
Laboratórios	protese_laboratorios por clínica	✅ Sim

• Acoplamento indevido: não encontrado acoplamento a "clínica única" — o clinica_id é onipresente.
• Ponto de atenção: o contexto é cacheado no localStorage (SCOREODONTO_USER_DATA, plugins) e reconciliado via hydrateMyPlugins(). Plugins ativos vivem em localStorage (cliente), não só no servidor — risco de divergência entre dispositivos (mitigado por me/plugins, mas é o elo mais frágil do multiempresa).
• O marketplace de salas é cross-tenant por desenho (uma clínica aluga sala de outra) — acoplamento intencional.

Veredito: conceito multiempresa bem respeitado no backend; a fragilidade é o estado de UI/plugins no cliente.

---

ETAPA 7 — MARKETPLACE

Salas (salas) ─┬─ Locação (sala_reservas: valor, modelo, status pendente/aceita)
               └─ Profissionais (perfil) ─ Propostas (propostas_profissional: mensagem)
                                         └─ Protéticos/Laboratórios (protese_*)

Frente	O que existe hoje	O que falta	Gera receita?	Pode gerar
Locação de salas	CRUD de salas, publicação no marketplace, reserva com valor e workflow de status (pendente→aceita), painel da sala	Gateway de pagamento e taxa da plataforma (hoje o valor é registrado, mas o pagamento é manual/externo)	Não diretamente	Sim — comissão sobre locação
Profissionais	Perfil público + envio de proposta (mensagem) clínica→profissional	Negociação, contrato, e qualquer cobrança	Não	Sim — taxa de match/assinatura premium
Protéticos / Laboratórios	OS, produtos, custo lab integrados ao financeiro/comissão	Marketplace aberto de laboratórios (hoje é interno por clínica)	Indireto (operacional)	Sim — rede de laboratórios
Tutoria de Ortodontia	Candidatura paga via MercadoPago (preferences + mp-webhook), comissao_pct, solicitações/mensagens	Escala (oferta de tutores), avaliação	✅ Sim (a única automatizada)	Já gera

Conclusão: a infraestrutura de marketplace existe, mas só a Tutoria tem captura de pagamento real. Salas é a frente mais próxima de monetizar (já tem valor e reservas) — falta o gateway + a taxa.

---

ETAPA 8 — FINANCEIRO

ORIGEM DO DINHEIRO                  →  DESTINO                       →  RESPONSÁVEL
Procedimento realizado (RECEITA)   →  financeiro (a receber)        →  Clínica
Contrato (gerar-cobranca)          →  financeiro (a receber)        →  Clínica
Convênio (recebíveis) − Glosa      →  financeiro / recupera         →  Clínica
Comissão (base − custo lab × %)    →  repasses (fechado)            →  Profissional
Repasse pago                       →  financeiro DESPESA (COMISSÕES) →  Clínica paga Profissional
Locação de sala (valor reserva)    →  sala_reservas (status)        →  Locador  [pagamento manual]
Tutoria (inscrição)                →  MercadoPago → ativa tutor     →  Plataforma (comissao_pct)

Item	Tabela	Estado
Orçamentos	orcamentos/orcamento_itens	✅ completo
Contratos	contratos/contrato_*	✅ completo (modelos, variáveis, assinatura, cobrança)
Convênios/Planos	planos, procedimentos_valores_planos	✅
Produção	procedimentos_realizados → financeiro	✅ (RECEITA opcional por valor)
Comissão	comissao_regras + computeComissoes	✅ (3 níveis de regra; abate custo lab)
Repasse	repasses (fechar/pagar/cancelar/comprovante)	✅ ciclo fechado, com estorno
Glosas	glosas (recorrer/recuperar)	✅ funcional, isolado do repasse
Locação	sala_reservas.valor	⚠️ registra valor, sem captura de pagamento

Pontos fortes: rastreabilidade (cada DESPESA de repasse referencia o período/profissional; audit_log em tudo), e não-duplicação de comissão (sem_comissao propagado). Lacuna: receita de procedimento depende de ação manual.

---

ETAPA 9 — MAPA DE CONEXÕES (Mermaid)

flowchart TD
  U[Usuário] --> WS{Workspace ativo}
  WS -->|clínica| CL[Clínica / RBAC]
  WS -->|sala| SH[Painel da Sala]

  CL --> LEAD[Leads]
  LEAD -->|converter| PAC[Pacientes]
  PAC --> AG[Agenda]
  AG --> AV[Avaliação]
  AG --> PR[Procedimento Realizado]
  PAC --> ORTO[Ortodontia]
  PAC --> RX[RX / Radiografias]
  PAC --> ORC[Orçamento]
  ORC --> CON[Contrato]
  CON -->|gerar-cobranca| FIN[Financeiro]
  PR -->|RECEITA| FIN
  PR --> COM[Comissão]
  PROT[Próteses / Custo Lab] --> COM
  COM --> REP[Repasse]
  REP -->|pagar DESPESA| FIN
  FIN --> GLO[Glosas]
  FIN --> REL[Relatórios]

  SH --> RES[Reservas de Sala]
  CL --> SAL[Salas Marketplace]
  SAL --> RES
  CL --> MKP[Marketplace Profissionais]
  MKP --> PROP[Propostas]
  ORTO --> TUT[Tutoria Orto]
  TUT -->|MercadoPago| MP[(Pagamento)]

  SUPER[SuperAdmin] --> CL
  SUPER --> PLUG[Plugins]

flowchart LR
  subgraph Núcleo financeiro
    PR[procedimentos_realizados] --> FINr[financeiro RECEITA]
    FINr --> CR[comissao_regras]
    CR --> RP[repasses]
    RP --> FINd[financeiro DESPESA]
    FINr --> GL[glosas]
  end

---

ETAPA 10 — OPORTUNIDADES

Funcionalidades órfãs (existem no código, ninguém usa)

• views/OrthoReports.tsx — não é roteada em App.tsx nem importada por nenhuma view. Órfã real (importa OrthoPhotoWorkspace, mas nada importa OrthoReports). Relatórios de ortodontia prontos e desligados.
• SyncView (/admin/sync) — tela e rota existem, mas isViewAllowed retorna false sempre. Código morto navegável.

Funcionalidades escondidas (existem mas não aparecem no menu)

• /update (UpdateDbView) — migração de banco; acessível por URL direta, fora do menu (ferramenta técnica).
• /cadastro-dentista — só alcançável por fluxo/magic-link; sem entrada no menu e com deep-link quebrado.
• Comissões deep-link — visível no menu (admin/donos) mas /comissoes direto cai em dashboard.

Funcionalidades incompletas (começam mas não terminam o fluxo)

• Locação de salas — reserva com valor e status, mas sem captura de pagamento (fluxo financeiro não fecha).
• Marketplace de profissionais — proposta é só mensagem; não evolui para contratação/cobrança.
• RECEITA de procedimento opcional — pode não gerar lançamento (receita potencialmente não registrada).
• Glosas isoladas — recuperam receita, mas não reconciliam com o repasse correspondente.

Funcionalidades de alto potencial (podem gerar receita)

1. Gateway na Locação de Salas (já existe valor+reserva): cobrança + taxa da plataforma → receita recorrente.
2. Assinatura/planos da plataforma (superadmin/pricing, assinaturas já existem): monetizar o SaaS por clínica.
3. Marketplace de Profissionais premium: taxa de match / destaque de perfil.
4. Tutoria de Ortodontia em escala (único pago hoje): aumentar oferta de tutores e volume.

---

RESULTADO FINAL

Notas (0–100) — com base nas evidências

Eixo	Nota	Justificativa (evidência)
Arquitetura funcional	72	Roteamento+RBAC robustos, mas server.js monolítico (516 KB), roteador próprio e 3 deep-links quebrados.
Integração dos módulos	78	Cadeia Lead→…→Repasse bem costurada, com auditoria e não-duplicação de comissão.
Fluxos de negócio	70	Núcleo clínico+financeiro completo; ramos de marketplace incompletos; receita às vezes manual.
Multiempresa	82	tenantGuard+clinica_id onipresentes; isolamento de sala; fragilidade no estado de plugins no cliente.
Marketplace	45	Infra existe; só Tutoria captura pagamento; Salas e Profissionais sem fechar fluxo financeiro.
Financeiro	80	Receita/despesa, comissão (3 níveis), repasse com estorno, glosas, contratos com cobrança.
Experiência do usuário	70	Menus por papel, nav mobile, "visualizar como"; prejudicada por deep-links quebrados e estado em localStorage.
Potencial de monetização	65	Tutoria já fatura; Salas e Assinatura SaaS são alavancas prontas e subutilizadas.

1. O que remover

• views/OrthoReports.tsx (órfã) — ou religar ao menu de Ortodontia se desejado.
• SyncView / rota /admin/sync e telas de sync global desativadas (já substituídas por backup por clínica).
• server.js.bak e scripts de transformação legados (transform.js, pg-convert.js) do diretório de produção.

2. O que corrigir

• Adicionar /comissoes, /glosas, /cadastro-dentista ao ROUTE_MAP (deep-link/refresh quebrado).
• Reconciliação de plugins ativos: tratar o servidor como fonte da verdade (reduzir dependência de localStorage).
• Tornar a geração de RECEITA do procedimento o padrão claro (evitar receita não registrada).

3. O que finalizar

• Locação de Salas: captura de pagamento + taxa da plataforma (fecha o fluxo financeiro do marketplace).
• Marketplace de Profissionais: evoluir proposta → contratação → cobrança.
• Relatórios: consolidar (há reports/productivity + telas parciais).

4. O que priorizar

1. Corrigir deep-links e estado de plugins (baixo esforço, destrava UX e confiabilidade).
2. Gateway de pagamento na Locação de Salas (alavanca de receita mais próxima).
3. Cobrança por assinatura da plataforma (superadmin/pricing+assinaturas já existem).

5. O que gera receita mais rapidamente

• Locação de Salas com pagamento — o valor e o fluxo de reserva já existem; falta só a captura + taxa.
• Assinatura SaaS por clínica — a base multiempresa e o pricing já estão prontos no superadmin.

6. Próximo módulo mais estratégico

• Monetização da plataforma (Billing/Assinaturas + taxa de marketplace de salas). É o que converte uma base técnica madura (ERP odontológico multiempresa funcional) em receita recorrente da plataforma — hoje só a Tutoria cobra. Tudo o mais já está construído; falta o módulo que fatura.

---

Nota de método: este mapa reflete exclusivamente o que foi encontrado no código em 19/jun/2026 (frontend/App.tsx, frontend/views/*, frontend/components/Sidebar.tsx, backend/server.js). Onde havia ambiguidade (ex.: receita opcional, pagamento manual de salas), o fato foi descrito como está, sem inferir intenção. Nenhuma funcionalidade foi inventada.