Onboarding PJ — Fluxo BPMN de Ponta a Ponta

Aprovar uma pessoa jurídica costuma virar uma colcha de planilhas, e-mails e prints: falta um documento, ninguém sabe quem está por trás da empresa, e a decisão fica sem registro. No DATTA, o onboarding PJ é um processo BPMN executável que conduz cada CNPJ da chegada do dossiê até a decisão humana registrada — sem nenhuma aprovação automática em nenhum ponto do caminho.

O modelo semente é o onboarding-pj-kyb.bpmn, versionado junto com os demais modelos da plataforma e orquestrado pelo Motor BPM. Cada instância nasce com a chave de negócio = CNPJ da empresa em análise e percorre triagem de completude, resolução de beneficiário final (UBO), análise societária e decisão do analista.

O fluxo em uma página

Dossiê recebido
  ▼
[Triagem de completude]  critérios KYB-COMP-1..3
  ▼
<Dossiê completo?>
  ├─ CONFORME ───────────────────────────────┐
  └─ default → [Solicitar documentos]        │
       → (espera "documentos-recebidos") ────┘   ← laço de completude
  ▼
[Resolução de beneficiário final]  datta:servico="ubo"
  ▼
[Análise societária e cruzamentos]  KYB-SOC-*, KYB-POD-*, KYB-CRUZ-*
  ▼
<Roteamento de risco>
  ├─ tudo limpo → [Decisão do analista — via simplificada]
  └─ default    → [Decisão do analista — análise reforçada]
  ▼
<Decisão> → aprovado | rejeitado | volta ao laço de completude

O laço de completude: o processo espera o documento sozinho

Quando a triagem de completude reprova o dossiê, o fluxo abre a tarefa humana Solicitar documentos e em seguida fica em espera.

Ao subir os documentos complementares pela tela de Upload — com o mesmo CNPJ alvo do dossiê —, a plataforma publica automaticamente a mensagem documentos-recebidos, correlacionada ao CNPJ, ao fim do lote. A instância acorda sozinha e refaz a triagem de completude. Nenhum passo manual de "retomar processo" é necessário.

A etapa de UBO é serviço, não triagem

A tarefa Resolução de beneficiário final é uma tarefa de serviço (datta:servico="ubo"): em vez de acionar a triagem por critérios, o motor chama a consulta de grafo que materializa a cadeia societária da Receita e da CVM (cross-link) e executa a travessia recursiva de percentuais.

O resultado entra na instância como variáveis escalares, prontas para os gateways decidirem:

Roteamento de risco: na dúvida, o caso sobe

A via simplificada só é tomada quando todas as condições valem ao mesmo tempo:

• fase societária CONFORME;
• nenhum beneficiário acima do threshold;
• nenhum vínculo com base negativa;
• zero divergências entre calculado e declarado;
• nenhuma anomalia crítica.

Qualquer outro cenário cai na análise reforçada — o caminho default do gateway. Na dúvida, o caso sobe, nunca desce.

Decisão humana, sempre registrada

As duas vias terminam em tarefa humana com formulário obrigatório:

• Decisão — aprovar, rejeitar ou pedir_documento;
• Motivo — texto livre obrigatório.

A via simplificada é uma fila com recomendação pré-preenchida, não um atalho de aprovação: o analista decide nas duas vias, e fica registrado quem decidiu, quando e com qual motivo — junto do critério e da versão do critério aplicada na triagem (ver Critérios KYC/KYB).

Escolher pedir_documento — ou qualquer decisão fora de aprovar/rejeitar — devolve o caso ao laço de completude.

Quem pode o quê

O aviso documentos-recebidos disparado pelo upload viaja pelo canal interno entre serviços da plataforma (com token de serviço) — não depende de sessão de usuário aberta.

Publicando o modelo

O modelo semente é publicado como qualquer outro:

1. Importe o arquivo na tela do Process Modeler e publique a versão. A plataforma também expõe endpoints para importar e publicar modelos — veja a referência de API.
2. Se quiser que toda :Empresa nova do contexto de dossiê abra instância automaticamente, ative o auto-início do modelo.
3. Confira que o contexto declarado no modelo (datta:contexto="OnboardingPJ") coincide com o nome do contexto de dossiê cadastrado em Sistema›Contextos›Gerenciar — é esse casamento que liga o processo aos dados certos.