saveinmed/docs/GAPS_ANALISE_B2B.md
2026-01-08 14:28:34 -03:00

4.6 KiB

Lacunas e requisitos pendentes (Marketplace B2B)

Status (pronto x faltando)

Pronto

  • Nenhum item confirmado como concluído nesta análise de lacunas.

Faltando

  • Itens listados nas seções abaixo.

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.