scoreodonto.com/doc/MARKETPLACE-TRANSACIONAL-PROTESE.md

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