# 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)

```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]
```

```mermaid
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.
</content>
</invoke>