VPS 4 Builder
6cd8c1f9e1
- A clínica avalia o laboratório (1-5★ + comentário) após a entrega (protese_avaliacao, 1 por OS, reavaliável). POST /protese/os/:id/avaliar; avaliação volta no GET detalhe. - Nota ScoreOdonto passa a combinar 0.6·operacional + 0.4·satisfação (estrelas) quando há avaliações. Selo "Verificado" (≥5 entregas). Exposto no marketplace (★nota · nº avaliações · Verificado) e nos indicadores do lab (KPI Satisfação). Helper notasScorePorProtetico unificado (dropdown + marketplace). - UI: seção "Avaliar o laboratório" na OS entregue (lado clínica); selo/avaliações no card do marketplace. - Correção de passagem: FileText/Star importados em ProteseView (FileText faltava desde a fatia 3). Validado em DEV: 6 entregas + 5★/3★ → nota 9.2, satisfação 4★, verificado (marketplace e indicadores). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
59 lines
4.1 KiB
Markdown
59 lines
4.1 KiB
Markdown
# Marketplace transacional de Prótese
|
|
|
|
> Desenho (24/jun/2026). O último grande item do backlog do Provedor de Prótese.
|
|
> Princípio: **transformar o diretório (descoberta) em jornada de compra** — descobrir → ver
|
|
> serviços/preços → solicitar → cotar → contratar → vira OS. Reaproveita ao máximo o que já existe.
|
|
|
|
## O que já existe (não recriar)
|
|
- **Descoberta:** `/api/profissionais/marketplace` (busca por proximidade/especialidade) **+ Nota
|
|
ScoreOdonto** no card (feito).
|
|
- **Catálogo:** `protese_produtos` (nome, preço, garantia) + `GET /api/protese/laboratorios/:id/produtos`
|
|
— já acessível a quem está no **diretório** (`proteticoAcessivelPelaClinica` aceita `disponivel_diretorio`).
|
|
- **Propostas:** `propostas_profissional` (clínica→profissional: mensagem, `pendente→aceita/recusada`).
|
|
- **Contratação:** a clínica **já cria OS para qualquer protético do diretório** (Nova OS).
|
|
- **Pós-venda:** OS completa (etapas, custódia, ocorrências), financeiro, score — tudo pronto.
|
|
|
|
**Conclusão:** o "transacional" não exige nova fundação — falta **costurar a jornada** dentro do
|
|
marketplace (hoje a clínica vê nome/nota/distância, mas não os serviços, e contrata por outra tela).
|
|
|
|
## Fatias
|
|
|
|
### ✅ Fatia 1 — Vitrine (catálogo no marketplace) — IMPLEMENTADA
|
|
No card do protético no marketplace, **"Ver catálogo"** expande os produtos (nome, preço, garantia)
|
|
via `getLaboratorioProdutos(id)` (reuso — zero endpoint novo). A clínica passa a **decidir vendo
|
|
serviços + preço + garantia + ★nota** antes de contratar. Botão de contato vira **"Solicitar
|
|
prótese"** (proposta com contexto de prótese).
|
|
|
|
### ✅ Fatia 2 — Solicitação → OS direto — IMPLEMENTADA
|
|
"Solicitar prótese" (card do protético) abre o `SolicitarProteseModal` — fluxo enxuto com o lab
|
|
**pré-selecionado**: produto do catálogo (ou descrição livre) + paciente (busca) + dentista + dentes
|
|
+ prazo + observações → **cria a OS** via `createProteseOS` (que já aceita lab do diretório, sem
|
|
vínculo prévio). Tela de confirmação com CTA para a Bancada. Optei por um modal próprio e auto-contido
|
|
(reusa getLaboratorioProdutos/getDentistas/getPacientes/createProteseOS) em vez de extrair a Nova OS —
|
|
menor risco. Validado em DEV: OS criada para lab do diretório (Coroa de Zircônia, status solicitado).
|
|
|
|
### ✅ Fatia 3 — Cotação (RFQ) — IMPLEMENTADA
|
|
Entidades novas `protese_rfq` + `protese_rfq_cotacao`. Fluxo: a clínica descreve o trabalho e
|
|
**convida N labs** → cada lab **cota** (valor/prazo/obs) → a clínica **compara** (ordenado por preço)
|
|
e **escolhe** → vira **OS** (custo = valor da cotação) e a RFQ fecha (demais cotações recusadas).
|
|
Endpoints: `POST/GET /protese/rfq`, `GET /protese/rfq/recebidas`, `POST /protese/rfq/cotacao/:id`,
|
|
`POST /protese/rfq/:id/escolher`. UI: lado lab = tela **Cotações** (`lab-cotacoes`, responde); lado
|
|
clínica = botão **Cotações** na tela de Prótese (pedir multi-lab + comparar + escolher). Validado em
|
|
DEV ponta a ponta (pedido → cotação R$420 → escolha → OS criada → RFQ fechada).
|
|
|
|
### ✅ Fatia 4 — Reputação (avaliação + selo) — IMPLEMENTADA
|
|
A clínica avalia o laboratório (1-5★ + comentário) **após a entrega** (`protese_avaliacao`, 1 por OS,
|
|
reavaliável). A satisfação **entra na Nota ScoreOdonto**: `0.6·operacional + 0.4·(estrelas/5·10)` (sem
|
|
avaliações = só operacional). **Selo "Verificado"** com ≥ 5 entregas. Exposto no marketplace (★nota ·
|
|
nº avaliações · Verificado) e nos indicadores do lab (KPI Satisfação). Endpoint `POST
|
|
/protese/os/:id/avaliar`. Validado em DEV: 6 entregas + avaliações 5★/3★ → nota **9.2**, satisfação 4★,
|
|
verificado, em marketplace e indicadores.
|
|
|
|
**Marketplace transacional concluído (Fatias 1-4).**
|
|
|
|
## Decisões de modelagem
|
|
- **Catálogo público = catálogo atual** (`protese_produtos`); a vitrine só o exibe — sem duplicar.
|
|
- **Solicitação reusa a OS** (não cria entidade paralela): toda contratação termina em `protese_os`,
|
|
preservando rastreabilidade/financeiro/score.
|
|
- **Cotação (Fatia 3)** é o único caso que precisa de entidade nova (pré-OS multi-lab).
|