Pular para o conteúdo principal

Parceiros (clientes e fornecedores)

Homologação da rota /parceiros, cadastro em /parceiros/novo e detalhe em /parceiros/:id para registos que não são tratados como funcionário no detalhe (kind === "partner"). Funcionários têm lista própria em /funcionarios, mas partilham rotas de cadastro/detalhe. Cenários incluem pendências de implementação.

Lista (/parceiros)​

  • Cabeçalho — Título “Parceiros” e subtítulo sobre clientes e fornecedores.
  • Permissão — Acesso com AdminSettings (rota protegida).
  • Novo Parceiro — Link para /parceiros/novo sem estado; utilizador escolhe tipo (cliente/fornecedor/outro).
  • Resumo (PartnerCardSummary) — Cartões: Total, contagem por tipo (fornecido por byType da API), Ativos, Inativos; ícones por tipo; loading e erro (“Não foi possível carregar o resumo.”).
  • Filtros — Busca nome/código/documento (reinicia página), tipo (todos, Cliente, Fornecedor, Outro — sem opção “Funcionário” na lista, por desenho), status ativo/inativo, Limpar Filtros.
  • Filtro tipo na API — partnerTypeId correto para cliente/fornecedor/outro.
  • Erro na lista — Mensagem sobre permissões ou servidor.
  • Tabela — Código, nome, tipo (badge + ícone), documento, email, telefone, status, ações.
  • Ver detalhe — /parceiros/{id} com vista de parceiro (tabs geral, endereços, documentos — sem aba Permissões).
  • Lista vazia — “Nenhum parceiro encontrado com os filtros aplicados.”
  • Paginação — 10 itens por página; controlo com total > 0.

Cadastro de parceiro (/parceiros/novo — tipo cliente/fornecedor/outro)​

  • Abas — Dados básicos, Endereços, Documentos (três colunas; sem aba Permissões).
  • Validação — Nome e tipo obrigatórios; toast se faltar.
  • POST parceiro — POST /api/partners com partnerTypeId, contactos, status, notas.
  • Endereços — Após criar, POST /api/partners/{id}/addresses para cada endereço preenchido (logradouro/cidade/cep).
  • Documentos — POST /api/partners/{id}/documents para cada documento com número.
  • Tratamento de erro — Falha em endereço/documento após criar parceiro: rollback, retry ou mensagem clara.
    Homologar comportamento atual (pode ficar parceiro sem parte dos filhos). (revisão desejada)
  • Sucesso — Toast e navegação para /parceiros/{id} ou lista.
  • Voltar — Para /parceiros (consistente).

Detalhe parceiro (/parceiros/:id)​

  • Rota .../novo como id — Redireciona para /parceiros/novo.
  • Loading / não encontrado — Estados e voltar para /parceiros.
  • Cabeçalho — Nome, tipo, status, código.
  • Editar — Abre cadastro em modo edição com dados carregados ou formulário dedicado.
    Hoje: botão “Editar” sem onClick/navigate. (pendência crítica de implementação)
  • Dados gerais — Nome, código, tipo, documento, status, email, telefone, data cadastro, observações.
  • Endereços e documentos — Listagem; estados vazios com mensagens.
  • Permissões — Não aplicável a parceiro comercial (apenas funcionário).

Coexistência com funcionários​

  • Mesmo URL /parceiros/:id — API devolve kind employee vs partner; UI correta em cada caso.
  • Lista de parceiros — Não é obrigatório listar funcionários aqui; filtro por tipo não inclui funcionário.

Funcionalidades alargadas (backlog)​

  • Edição de parceiro — PUT /api/partners/{id} a partir do detalhe ou página dedicada; atualizar endereços/documentos.
  • Exclusão — DELETE /api/partners/{id} com confirmação na UI.
    Mutação existe; pode faltar botão. (pendência de UI)
  • Exportar lista — CSV/Excel. (opcional)
  • Debounce na busca — (melhoria)

Regressão​

  • Tipos e rótulos — PARTNER_TYPE_LABELS coerentes com a API.
  • Documentos sensíveis — Apenas utilizadores autorizados vêem detalhe completo.

A conclusão da homologação de “Parceiros” depende de implementar o fluxo de edição a partir do detalhe.