saveinmed/docs/GAPS_ANALISE_B2B.md

Lacunas e requisitos pendentes (Marketplace B2B)

Este documento descreve o que falta para cumprir o cenário solicitado:

• Comprador só descobre o vendedor no final do fluxo.
• Taxa invisível de 12% (não pode ser mostrada ao comprador).
• Comissão do vendedor de 6% (sugestão do usuário: “vai ficar 6% para vendedor”; confirmar regra de negócio e origem dos 6%).

Observação: a regra atual citada na documentação do backend indica taxa invisível de 12% para compradores. Antes de implementar, alinhar o modelo final de taxas (12% buyer fee + 6% seller fee? 12% total? split?).

---

1) Backend (Go API)

1.1 Regras de negócio / taxas

• Definir modelo final de taxas (12% para comprador, 6% para vendedor):
  • esclarecer se são duas taxas distintas ou partes de uma taxa total.
  • documentar em config (ex.: BUYER_FEE_RATE, SELLER_FEE_RATE) e no Swagger.
• Normalizar cálculo de preços:
  • guardar preços base (seller price) e final (buyer price) com rastreabilidade.
  • garantir que a taxa não aparece em payloads do comprador.
• Auditoria de taxas:
  • registrar no pedido: base_price, buyer_fee_rate, buyer_fee_amount, seller_fee_rate, seller_fee_amount, payout_amount.
  • expor esses campos somente para backoffice/admin.

1.2 Ocultação do vendedor

• Mascarar dados do vendedor nos endpoints públicos do catálogo/pesquisa:
  • retornar apenas atributos neutros (ex.: distância, categoria, SLA, estoque, validade) sem identidade.
• Revelar vendedor somente no final:
  • definir claramente qual evento é “final” (ex.: confirmação do pagamento, confirmação do pedido).
  • criar endpoint específico para revelação pós-compra.

1.3 Contratos de API

• Revisar schemas do Swagger para refletir:
  • campos mascarados antes da compra;
  • campos completos após compra;
  • campos financeiros internos (somente backoffice/admin).
• Versionar mudanças (ex.: /api/v1 → /api/v2 se necessário para evitar breaking change).

1.4 Segurança e compliance

• Garantir controle de acesso:
  • comprador não pode inferir vendedor por id, slug ou dados indiretos.
• Logs de auditoria para preço final vs. preço base.
• Testes automatizados garantindo que vendedor não aparece em respostas pré-compra.

---

2) Frontend (Marketplace React)

2.1 Ocultação do vendedor no fluxo

• Remover nome/identidade do vendedor das telas de catálogo/listagem/carrinho.
• Substituir por informações neutras:
  • faixa de SLA, localização genérica (ex.: “Região Metropolitana”), disponibilidade, avaliações agregadas.
• Bloquear UI que revele vendedor antes do “evento final”.

2.2 Exibição de preços

• Mostrar somente preço final (com taxa invisível aplicada), sem linha de “taxa”.
• Texto/tooltip neutro (ex.: “preço final do produto”).

2.3 Ponto de revelação

• Tela pós-compra com dados completos do vendedor.
• Estados intermediários (checkout, pagamento pendente) sem revelar vendedor.

---

3) Frontend principal (saveinmed-frontend)

Se este frontend também for usado por compradores/vendedores finais, as mesmas regras acima precisam ser espelhadas.

• Revisar listagens para garantir que vendedor não aparece antes da compra.
• Revisar preços para exibir apenas valor final (taxa invisível).
• Revelação pós-compra na área de pedidos.

---

4) Backoffice (NestJS)

4.1 Administração de taxas

• Tela e endpoints para configurar:
  • buyer_fee_rate (ex.: 12%).
  • seller_fee_rate (ex.: 6%).
• Histórico de alterações e auditoria.

4.2 Visibilidade e auditoria

• Dashboard financeiro com:
  • preço base, preço final, taxas, payout do vendedor.
• Exportação para contabilidade (CSV/Excel).

4.3 Compliance

• Logs de decisão (por pedido) demonstrando que comprador não viu taxa.

---

5) Alinhamentos necessários (negócio + produto)

• Definir “momento final” de revelação do vendedor.
• Definir regra de taxa (12% buyer + 6% seller ou modelo único).
• Definir termos legais (taxa invisível, transparência fiscal para vendedor).
• Definir experiência de suporte (ex.: disputa, devolução) sem expor vendedor antes da compra.