Associados — Fluxos

Atores e acesso

Camada	Comportamento
Admin → páginas por role	Configurável (kunk.role_pages)
Default	Todas as roles staff (Administrador, Acolhimento, Produção, …)
Roles típicas	Acolhimento e Administrador usam esta página no dia a dia

Roles staff entram no app Kunk; menu/rotas filtram por role_pages.

---

1. Listagem (cadastramento)

Abrir /app/acolhimento/associados
 → GET últimos N responsáveis (default N=60; “Carregar mais” aumenta)
 → excluir status=patient da lista principal
 → cards de contagem por fase/status do funil
 → tabela: avatar · nome · e-mail · telefone · status · criado
 → pesquisa local na tabela (nome, e-mail, telefone, paciente vinculado)

Deep link do search / atalhos

?a={user_code}
 → carrega só esse user (+ pacientes via responsible_code)
 → abre modal do associado

Criar associado (painel)

Botão "Criar Associado"
 → modal com e-mail (mínimo)
 → POST cria users (associate_status=1, status conforme regra do funil)
 → associado aparece na lista / pode abrir modal

createAssociate.jsx (só e-mail no painel). O funil completo continua no app registration.

Enviar para triagem

Na linha (ou no search), se status concluído (Associado):

Ação "Enviar para triagem"
 → POST reception com dados do associado
 → redirect /app/acolhimento/triagem (ou abre fila)

---

2. Modal do associado

Abrir modal (avatar / clique / ?a=)
 Header: avatar · nome · "Associado desde …"
 · [Tornar associado] (se ainda em funil)
 · menu Termo (Novo Termo / Copiar link) — ações mostram indisponibilidade enquanto o módulo de termos não estiver ativo
 Abas:
 0 Dados Pessoais
 1 Pacientes
 2 Prescritor
 3 Anotações
 4 Documentos
 5 Histórico

2.1 Dados pessoais

• Form editável (nome, CPF, RG, nascimento, gênero, nacionalidade, estado civil, tel, e-mail, endereço, motivo texto)
• CIAP2 (ciap_codes + texto)
• Salvar → PATCH user
• Excluir → só se sem pedidos, serviços nem pacientes vinculados (409 caso contrário)

2.1b Tornar associado

Botão no header (se ainda não for Associado):

Confirmar
 → status = "Associado"
 → associate_status = 5
 → sem gerar termo / sem adhesion_term

2.2 Pacientes

Lista pacientes WHERE responsible_code = associado.user_code
 · accordion por paciente
 · editar dados + CIAP
 · excluir paciente (bloquear se serviços com patient_user_code)
 · criar paciente (CreatePatient)

SEM botões "Tornar Ativo" / "Remover Ativo"

Mudança vs histórico: não há mais “paciente ativo” operacional no painel. O vínculo estrutural é responsible_code no paciente.

users.patient_user_code no responsável continua sendo preenchido pelo funil (responsible_type=another) — aponta o paciente cadastrado no funil. Uso no painel:

Uso	Comportamento
Lista / subtítulo	Pode exibir o nome desse paciente se o código for válido
Serviços (?u= / create)	Pré-selecionar esse paciente como beneficiário se existir e for filho do responsável
Template do serviço	Usa só services.patient_user_code gravado no atendimento

2.3 Prescritor

• Campo texto livre prescriber (nome)
• prescriber_code opcional (se operador colar/vincular código)
• Data da receita (date_prescription)
• Upload de receita via FileUpload com kind="prescription"
• Sem autocomplete obrigatório de professionals; sem Parceiro

2.4 Anotações

Campo users.annotations = JSON array
 item: { id, text, date_created, userName, user_code? }
 · adicionar → PATCH imediato
 · excluir → PATCH imediato
Autor = system_user logado (nome exibido)

Anotações são da equipe de acolhimento sobre o associado — não são mensagens do associado.

2.5 Documentos

Reutilizar apps/kunk/src/components/files/FileUpload.jsx + documentKinds.js:

1. Selecionar tipo (Documento do Associado / paciente / Receita / Laudo / Exame)
2. Escolher arquivo → renomeia {prefix}{nome}-{sobrenome}-{user_code}.{ext}
3. Upload → files + users_files (doc_kind, subject, …)

Mesma lógica do uploader já implementado no Kunk.

2.6 Histórico

GET pedidos do user_code
GET serviços do user_code (associate_user_code)
 → lista unificada ou duas seções, mais recente primeiro

Colunas no espírito anteriores (associateHistory.jsx).

2.7 Termo de adesão

UI (header):
 · "Novo Termo"
 · "Copiar link do Termo" (se adhesion_term existir)

Comportamento atual (módulo indisponível):
 · Qualquer ação → no-op / "Módulo de termos indisponível"
 · NÃO grava adhesion_term; NÃO muda status

Com doc-sign ativo:
 1. Gerar termo → status/label "Termo criado"
 2. Assinar → status atualizado pelo app de termos → Associado

---

3. Serviços — seleção do beneficiário

Observações/agenda usam responsável + paciente via patient_user_code no responsável quando aplicável.

Novo fluxo:

Modal Novo Serviço
 1. Buscar / selecionar associado responsável
 2. Selecionar beneficiário do atendimento:
 ○ O próprio associado responsável
 ○ Paciente X (lista GET /users/:id/patients)
 Default: se responsável.patient_user_code válido → pré-seleciona esse paciente
 3. Profissionais, valores, data, tags… (como hoje)
 4. Criar

Persistência no serviço:

Campo	Quando beneficiário = responsável	Quando = paciente
associate_user_code / name / email	responsável	responsável (sempre)
patient_user_code	null	user_code do paciente
patient_name	null ou nome do responsável (opcional)	nome do paciente

Observações / evento de calendário / templates usam dados do paciente escolhido + dados do responsável quando há paciente; senão só o responsável.

Ver atualização em ../servicos/flow (seção beneficiário) e fields.

---

4. Search global → associados

Ver ../search-global/flow.

Resumo: resultado associado abre /app/acolhimento/associados?a={code} (nova aba, como no produto) e oferece ação Triagem.

---

5. Status / fases na lista

Mapear para labels de UI (cards + filtros + coluna Status). Fonte de verdade:

Condição	Label UI
status = Associado	Associado
status = patient	(não lista como responsável)
associate_status = cadastro_criado	Não preencheu os dados
associate_status = dados_pessoais	Apenas preencheu os dados
associate_status = documentos	Documentos enviados
associate_status = assinatura_termo (não Associado)	Termo criado
invalid_fields não vazio	Problema no cadastro

Compatibilidade de leitura com strings legadas migradas (published, registered, proofs, signedcontract, …) via mapa no server ou na UI — ver fields.