VPS 4 Builder
5b99292b2d
- documentação/MAPA-FUNCIONAL-COMPLETO.md: inventário de rotas/telas/botões/fluxos, matriz de módulos, mapa de conexões (mermaid) e notas — baseado em evidências do código. - documentação/AUDITORIA-ESTRATEGICA-MODELAGEM.md: análise Pessoa→Vínculo→Workspace, entidades mal classificadas e riscos arquiteturais. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
486 lines
30 KiB
Markdown
486 lines
30 KiB
Markdown
# 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>
|