Regras de negócio · Atendimento
RN-ATENDIMENTO-001 · Cliente obrigatório
Condição e resultado:
Todo Registro de Atendimento é criado com person_id e uma Pessoa legível pelo ator. O campo não pode ser preenchido depois.
RN-ATENDIMENTO-002 · Unidade e núcleo
Condição e resultado:
unit_id identifica a unidade responsável e não o local físico. responsible_nucleus_sigla identifica o núcleo que governa o alcance de leitura e escrita. A Pessoa, a unidade e o núcleo devem ser válidos no momento da operação.
RN-ATENDIMENTO-003 · Modalidade
Condição e resultado:
mode é fixo. REMOTO exige exatamente service_record_remote_details; PRESENCIAL exige exatamente service_record_onsite_details. Cada detalhe tem id próprio e relação única com o registro.
RN-ATENDIMENTO-004 · Origem e estados
Condição e resultado:
origin aceita ESPONTANEO, ROTA ou AUTOMACAO na entrada. AGENDAMENTO é inferida quando isAppointment=true, que inicia o registro em AGENDADO. Sem essa marca o estado inicial é EM_ESPERA. O ciclo sequencial é AGENDADO → EM_ESPERA → EM_ATENDIMENTO → EM_REVISAO → ENCERRADO. O encerramento direto também parte de qualquer estado não terminal, em atendimento remoto ou presencial, com conclusão para todos os assuntos; cancelamento gera CANCELADO. Estados encerrado e cancelado são terminais.
RN-ATENDIMENTO-005 · Concorrência
Condição e resultado:
Todo comando exige expectedVersion igual à versão persistida e incrementa version. A idempotency_key é exclusiva da criação; repetir a chave devolve o registro já criado.
RN-ATENDIMENTO-006 · Assuntos
Condição e resultado:
Um atendimento possui um ou mais assuntos. ENTREVISTA_INAUGURAL exige consultation_id; ACOMPANHAMENTO exige entrevista ou processo; FINANCEIRO exige case_id e fee_contract_id; referências devem pertencer à mesma Pessoa e ser legíveis pelo ator.
RN-ATENDIMENTO-007 · Conclusões
Condição e resultado:
Cada assunto admite no máximo uma conclusão. PROVIDENCIAS indica trabalho decorrente; SEM_INTERCORRENCIA indica ausência de providência. A nota tem de 1 a 20.000 caracteres. O encerramento exige uma conclusão em todos os assuntos.
RN-ATENDIMENTO-008 · Participantes
Condição e resultado:
Participantes são pares únicos de registro e usuário. O usuário precisa estar ativo e lotado no núcleo responsável. Transferência remove a participação anterior e insere a nova; liderança de núcleo é necessária para distribuir.
RN-ATENDIMENTO-009 · Alcance e erros
Condição e resultado:
O serviço decide autorização por registro. Registro inexistente e registro fora do alcance respondem 404 NOT_FOUND sem revelar existência. Entrada inválida, falta de autenticação, falta de perfil, conflito de versão e violação de regra usam respectivamente 400, 401, 403, 409 e 422 com errorCode.
RN-ATENDIMENTO-010 · Responsabilidades no fluxo
Condição e resultado:
O operador autorizado cadastra o atendimento e define os assuntos. O atendente realiza o atendimento, registra as conclusões dos assuntos e encerra o atendimento.
Todos os usuários autorizados a criar atendimentos também podem consultar e editar atendimentos no alcance permitido, respeitando as restrições de estado e versão.
Operador e atendente identificam responsabilidades distintas no fluxo, sem vinculação a cargos ou novas permissões na API.
RN-ATENDIMENTO-011 · Origem e responsabilidade da Solicitação
Condição: Criação de uma Solicitação.
Resultado: O Registro de origem deve ser gravável. A Pessoa é herdada e o assunto opcional precisa pertencer ao Registro e ser legível. Deve existir ao menos um item e exatamente um responsável: usuário ativo com alcance institucional ou sobre o núcleo, ou grupo habilitado.
RN-ATENDIMENTO-012 · Cumprimento dos itens
Condição: Recebimento ou avaliação de um item.
Resultado: O recebimento parte de PENDING ou REJECTED, exige Registro de cumprimento gravável da mesma Pessoa e cria uma apresentação sequencial. DOCUMENT exige documento do dossiê. RECEIVED pode avançar para VALIDATING, ACCEPTED ou REJECTED; VALIDATING pode avançar para ACCEPTED ou REJECTED. A dispensa aceita PENDING, RECEIVED, VALIDATING ou REJECTED e produz WAIVED. Aceite e dispensa preenchem o instante de resolução.
RN-ATENDIMENTO-013 · Situação agregada, prazo e cancelamento
Condição: Consulta da Solicitação ou comando de cancelamento.
Resultado: O cancelamento prevalece e produz CANCELED. Sem cancelamento, todos os itens aceitos ou dispensados produzem COMPLETED; ao menos um resolvido, recebido ou em validação produz PARTIAL; os demais conjuntos produzem PENDING. overdue é verdadeiro quando há prazo passado, item não resolvido e ausência de cancelamento. Encerrar o Registro de origem não resolve seus itens automaticamente.
RN-ATENDIMENTO-014 · Versões e idempotência de Solicitações
Condição: Comando sobre Solicitação ou item.
Resultado: Receber, validar, aceitar, recusar e dispensar usam a versão do item, que é incrementada. Cancelar e vincular atividade usam a versão da Solicitação, que é incrementada. A mesma chave e comando compatível retornam o estado consultável sem repetir efeitos; mudança de conteúdo, versão divergente, Solicitação cancelada ou transição incompatível geram 409 CONFLICT. O replay reconhecido é tratado antes das validações de versão e cancelamento.
RN-ATENDIMENTO-015 · Leitura e vínculos da Solicitação
Condição: Consulta ou tratamento de uma Solicitação existente.
Resultado: A autorização depende da leitura do Registro de origem, inclusive após seu encerramento. Recebimento também exige gravabilidade do Registro de cumprimento. Vínculo de atividade exige atividade legível da mesma Pessoa. Projeções omitem apresentações e atividades sem alcance; omissão não equivale a exclusão.
RN-ATENDIMENTO-016 · Configuração, recorrência e calendário de Rotas
Condição: Configuração de Rota e geração de Ocorrência.
Resultado: A configuração exige liderança e alcance; responsáveis devem estar ativos e ter alcance sobre o núcleo. O intervalo usa a data UTC de criação da Rota como âncora. Frequência diária conta dias; semanal considera semanas iniciadas na segunda-feira e dias selecionados; mensal considera meses, dias selecionados e a faixa de sete dias indicada por weekOfMonth (1 a 5). Datas anteriores à âncora são recusadas.
A política next_business_day desloca dia não útil para o próximo útil; previous_business_day desloca para o anterior; skip gera effectiveDate=null e status=skipped. Uma data já útil é preservada. A mesma Rota/data solicitada é única; duas Ocorrências da mesma Rota não podem ocupar a mesma data efetiva não nula.
RN-ATENDIMENTO-017 · Execução e estados da Ocorrência
Condição: Criação de Ocorrência ou comando de execução.
Resultado: O executor deve ter alcance; perfil operacional-restrito também precisa constar entre os responsáveis. planned pode iniciar; in_progress pode concluir; ambas podem ser canceladas. completed, cancelled e skipped são terminais. Transições exigem a versão atual e a incrementam, preenchendo início ou fim. Repetir o estado de destino com a versão imediatamente anterior retorna a Ocorrência sem repetir o efeito.
RN-ATENDIMENTO-018 · Paradas e atendimentos presenciais
Condição: Criação de Parada, marcação de visita ou vínculo de atendimento.
Resultado: A posição é única por Ocorrência. Criar nova Parada ou vincular atendimento exige Ocorrência planned ou in_progress. Chegada e saída exigem in_progress, e saída exige chegada. Replays preservam os instantes. Somente atendimento presencial gravável pode ser vinculado; repetir a mesma Parada é idempotente, e vínculo com outra Parada gera conflito. O vínculo não usa expectedVersion e não incrementa a versão do ciclo do Registro.
RN-ATENDIMENTO-019 · Registro manual de Interações
Condição: Registro de contato já ocorrido.
Resultado: O Registro deve ser gravável. O canal manual não inclui WhatsApp; a operação aceita telefone, e-mail, vídeo, presencial ou nota, grava direção, resumo, instante, autoria e entrega RECORDED. A chave é única por Registro; replay equivalente preserva o registro, e conteúdo divergente gera conflito. A versão do ciclo do Registro não é alterada.
RN-ATENDIMENTO-020 · Envio, sincronização e entrega
Condição: Operação externa de Interação.
Resultado: Envio usa texto, modelo ou transferência e mantém o resultado da saída externa: SIMULATED ou SENT. Saída malsucedida não cria interação enviada. Sincronização consulta as mensagens selecionadas, exige instante e impede duplicidade da mesma mensagem no Registro; a entrega é SYNCED, com direção derivada da mensagem e autoria local nula. Lista vazia retorna synced-empty. Tokens de sistema precisam do escopo de sincronização e de dono ativo com alcance. Envio e sincronização usam recibos com impressão do conteúdo para detectar replay divergente.