VPS 4 Builder
b5d093d2ce
doc/MARKETPLACE-TRANSACIONAL-PROTESE: desenho do transacional (vitrine → solicitação → cotação → reputação), reusando catálogo/propostas/OS/score existentes. Fatia 1: no card do protético no marketplace, "Ver catálogo de próteses" expande os produtos (nome, preço, garantia) — reusa getLaboratorioProdutos (o catálogo já é acessível a quem está no diretório, zero endpoint novo). Botão de contato vira "Solicitar prótese". A clínica passa a decidir vendo serviços + preço + garantia + ★nota antes de contratar. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2.8 KiB
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 (proteticoAcessivelPelaClinicaaceitadisponivel_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
"Solicitar prótese" abre um fluxo enxuto (produto do catálogo + paciente + dentes + prazo + obs) que
cria a OS já com o lab selecionado (reusa POST /api/protese/os). Requer extrair o seletor de
paciente/dentista da Nova OS para um componente reutilizável fora da tela de Prótese.
Fatia 3 — Cotação (RFQ) para trabalho sob medida
Quando não há produto de catálogo: a clínica descreve o trabalho e N labs cotam (preço + prazo);
a clínica escolhe e vira OS. Estende propostas_profissional com itens de prótese e valores, ou nova
protese_rfq + protese_rfq_cotacao.
Fatia 4 — Reputação pública e conversão
Avaliação da clínica ao final da OS (alimenta a Nota, hoje só operacional), selo "lab verificado", ordenar marketplace por nota dentro do raio.
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).