Módulos do Sistema
Clientes e Regionais
Clientes, unidades regionais, contatos, endereços e benefícios.
No produto, o termo correto é Regional. No backend, a entidade ainda se chama ClientUnit.
| Produto | Backend | Frontend |
|---|---|---|
| Cliente | ClientEntity | src/features/client |
| Regional | ClientUnitEntity | src/features/client/hooks/ClientUnits |
| Contato do cliente | ClientContactEntity com client | contactService.ts |
| Contato da regional | ClientContactEntity com clientUnit | contactService.ts |
| Benefício | BenefitEntity + associação com valor | src/features/benefit e schemas de cliente |
O que precisa estar claro na interface
- Cadastro de cliente deve seguir o mesmo padrão visual usado em vagas.
- Edição de cliente também deve seguir esse padrão, sem quebrar regionais.
- A aba de regionais no modal de cadastro pode ser removida quando o fluxo de criação não precisar disso.
- Campos de endereço preenchidos não devem continuar acusando obrigatoriedade.
- Ao adicionar novo contato e tentar excluir contato antigo, exibir alerta.
Regras de modelagem
- Uma vaga pode referenciar um cliente ou uma regional.
- Contato pertence a cliente ou regional, nunca aos dois ao mesmo tempo.
- Benefícios vêm de catálogo, mas o valor pode variar por cliente ou regional.
Endpoints principais
| Recurso | Base | Permissões |
|---|---|---|
| Clientes | /gnoqcore/v1/client | client:* |
| Regionais | /gnoqcore/v1/client-units | client_unit:* |
| Contatos de cliente | /gnoqcore/v1/client/{clientId}/contact | client_contact:* |
| Contatos de regional | /gnoqcore/v1/client-units/{clientUnitId}/contact | client_unit_contact:* |
| Benefícios | /gnoqcore/v1/benefit | leitura pública pela API |
Referência detalhada: Backend / Clientes.