Regras de Negócio · Emergency Fluig

1 · Visão geral

A Emergency Documentação (grupo TCGI) atua há mais de 30 anos na obtenção de certidões e na regularização documental para escritórios, incorporadoras, imobiliárias e pessoas físicas, com atuação nacional. Na avaliação feita na reunião, a operação se assemelha mais a um serviço de despachante documental do que a uma gestão imobiliária tradicional — o que direcionou a solução para o Fluig, e não para um software de gestão de imóveis.

1.1 · Situação atual

• ERP próprio, desenvolvido internamente em PHP, que já cobre cadastro, orçamento, explosão de itens, expedição e faturamento.
• Robô de automação próprio, que emite certidões nos portais de diversos órgãos públicos.
• E-commerce próprio de autoatendimento, com pagamento por gateway e download do documento pronto — sem esteira de acompanhamento para o cliente.
• Tentativa anterior de implantar SAP, malsucedida por excesso de customização e lentidão resultante.

1.2 · Dores que motivam o projeto

1.3 · Fronteira da solução

Definição acordada na reunião: o Fluig assume a esteira operacional; o ERP próprio permanece como sistema de registro do financeiro.

1.4 · Princípios do desenho

• O cliente final não consome licença Fluig — acessa por link público assinado, com validade.
• O portador atua em campo pelo celular; a tarefa é atribuída nominalmente, com prazo.
• A origem do recurso é obrigatória antes de qualquer desembolso — é a trava que resolve a dor prioritária.
• Notificações apenas por e-mail. Não há integração com WhatsApp neste escopo.
• O Fluig não calcula nem armazena o financeiro como fonte: apura e entrega ao ERP.
• Faturamento parcial é permitido — item concluído pode ser faturado com outros ainda em andamento.

2 · Glossário

3 · Atores e papéis

Estimativa de usuários licenciados: confirmar na visita guiada — depende do número de atendentes, expedidores e portadores em operação simultânea.

4 · Modelo de dados

4.1 · Hierarquia

Cliente (do ERP)
 └── Pedido / protocolo            EMG-AAAA-NNNNN
      ├── Item de orçamento        serviço × quantidade
      │    └── Item expedido       1 por matrícula / nome / CNPJ   ← explosão
      │         ├── Desembolso     valor pago + comprovante + origem do recurso
      │         └── Documento      arquivo emitido (ECM)
      ├── Documento solicitado     procuração, RG, contrato social
      └── Fechamento               apuração enviada ao ERP

4.2 · Campos principais do formulário

5 · Regras por fase

5.1 · Comercial

• RN-01 · Toda solicitação gera um protocolo único, independente do canal de entrada (portal, atendimento ou indicação).
• RN-02 · O cadastro do requerente e a tabela de serviços são lidos do ERP. O Fluig não mantém cadastro próprio de cliente nem de preço.
• RN-03 · O perfil PF ou PJ define a condição de pagamento automaticamente: PF exige adiantamento integral, PJ segue a condição contratual com data de corte.
• RN-04 · Emolumento, custa e honorário são registrados separadamente por item desde o orçamento.
• RN-05 · O prazo estimado do pedido é o do item de maior prazo, não a soma dos prazos.
• RN-06 · A proposta é publicada no portal do cliente e notificada por e-mail. Cada revisão gera nova versão, com histórico preservado no processo.

5.2 · Expedição

• RN-07 · A explosão de itens gera uma linha por matrícula, nome ou CNPJ. Cada linha tem status, prazo e responsável próprios.
• RN-08 · O sistema classifica cada item em robô ou portador conforme o serviço do catálogo. A classificação pode ser alterada manualmente pela Expedição.
• RN-09 · Itens que exigem procuração ou documento do cliente ficam bloqueados até a documentação ser conferida e aprovada.
• RN-10 · Documento recusado retorna ao cliente com a exigência descrita, em loop, até ficar conforme.
• RN-11 · Falha do robô afeta apenas o item em questão; os demais itens do mesmo pedido seguem.
• RN-12 · Item em exigência do órgão retorna ao início da emissão após tratamento, sem reabrir o pedido inteiro.

5.3 · Prestação de contas

• RN-13 · A origem do recurso é obrigatória antes da liberação do numerário ao portador.
• RN-14 · Não é permitido adiantar contra saldo do cliente valor superior ao saldo disponível.
• RN-15 · Todo desembolso com valor maior que zero exige comprovante anexado.
• RN-16 · Divergência entre previsto e pago acima de 20% exige justificativa textual. confirmar percentual
• RN-17 · O Financeiro não concilia enquanto houver desembolso sem comprovante.
• RN-18 · A sobra do adiantamento é devolvida ao caixa e registrada como devolução do portador.

5.4 · Entrega e faturamento

• RN-19 · O documento fica disponível ao cliente no momento em que é conferido e anexado — sem etapa manual de envio.
• RN-20 · Faturamento parcial é permitido: apenas itens concluídos entram no fechamento.
• RN-21 · O valor faturado usa o emolumento real apurado na prestação de contas, não o valor orçado.
• RN-22 · Desembolsos de fundo fixo entram no fechamento como reembolso à Emergency.
• RN-23 · Clientes PJ têm os pedidos concluídos acumulados até a data de corte e fechados em fatura única.
• RN-24 · O Fluig envia o apurado ao ERP; a nota fiscal e o título são gerados lá.

6 · Controle de numerário

Esta seção detalha o tratamento da dor prioritária. O princípio é simples: todo movimento de dinheiro declara sua origem no momento em que acontece, e não em uma conciliação posterior.

6.1 · Duas contas separadas

6.2 · Ciclo do numerário

1. Designação    → declara origem + libera valor ao portador
2. Diligência    → portador paga emolumento no cartório
3. Prestação     → lança valor pago + anexa comprovante + confirma origem
4. Conferência   → Financeiro aceita ou devolve
5. Conciliação   → separa consumo do cliente × desembolso próprio
6. Faturamento   → cobra emolumento real + honorário + reembolso de fundo fixo

6.3 · Indicadores que passam a existir

• Numerário em poder de portadores, a qualquer momento.
• Saldo antecipado por cliente, com extrato de consumo.
• Capital próprio aplicado em pedidos, ainda não reembolsado.
• Desvio médio entre emolumento orçado e emolumento real, por órgão.
• Tempo médio entre desembolso e prestação de contas, por portador.

7 · Eventos e timers

Todos os prazos são parametrizáveis por tipo de serviço e por cliente. confirmar defaults

8 · Validações

Implementação de referência em prototipo/events/process-events.js.

9 · Integrações

9.1 · ERP próprio (PHP)

Cadastro no Fluig em Painel de Controle → Serviços, com autenticação por token e timeout curto, para que o Boundary Error assuma rapidamente em caso de indisponibilidade. confirmar se o ERP já expõe API REST ou se será necessário construir os endpoints

9.2 · Robô de certidões

Acionado como ServiceTask. O Fluig envia serviço, objeto e dados do requerente; o robô devolve o documento emitido ou o motivo da falha. confirmar interface disponível — API, fila ou diretório monitorado

9.3 · ECM

Documentos emitidos e anexos do cliente ficam no ECM do Fluig, com controle de versão e registro de download. Isso substitui a troca de arquivos por e-mail.

10 · Notificações

Canal único: e-mail, via SMTP corporativo da Emergency. confirmar servidor e domínio de envio

11 · Datasets Fluig

12 · Parâmetros

Todos com valores a validar com a Emergency. confirmar

13 · Permissões

14 · Premissas de escopo

Esta especificação parte das premissas abaixo, acordadas entre Mountain, TOTVS e Emergency. Elas delimitam a fronteira de responsabilidade da entrega Fluig e valem como base para a estimativa de esforço.

14.1 · Viabilidade técnica das integrações

Considera-se que todas as integrações previstas — ERP próprio, robô de certidões e demais sistemas envolvidos — já passaram por análise de viabilidade técnica e que as interfaces necessárias estão disponíveis e documentadas no momento do início da construção.

14.2 · Fronteira de responsabilidade

O funcionamento dos sistemas integrados não está sob responsabilidade do Fluig nem da equipe de implantação. O Fluig responde pelo fluxo: orquestração das etapas, chamada dos serviços, tratamento de falha e continuidade do processo.

14.3 · O que o desenho faz para sustentar a premissa

Para que a fronteira acima se sustente na prática — e não apenas no contrato — o processo foi desenhado de forma que uma falha externa fique visivelmente atribuída à sua origem:

• Toda ServiceTask tem Boundary Error. Falha externa direciona para diagnóstico e reprocessamento; o processo não trava nem perde o trabalho já feito.
• Falha é isolada por item. Um item que falhou no robô não impede os demais itens do mesmo pedido de seguirem.
• A comunicação nomeia a origem. No portal, o status de um item aguardando órgão público é "aguardando o órgão", não "processando". A atribuição de responsabilidade fica evidente para o cliente final.
• O ERP é o razão financeiro. O Fluig reserva e confirma contra o saldo, sempre relendo a origem. Não mantém saldo próprio, o que elimina divergência entre os dois sistemas.
• Envio de fechamento é idempotente. A chave é o protocolo do pedido: reenvio após timeout não gera cobrança duplicada.

14.4 · Demais premissas

• Notificações por e-mail, com SPF e DKIM configurados no domínio de envio da Emergency.
• Assinatura física de documentos. Não há assinatura eletrônica neste escopo.
• O robô de certidões é mantido como está, passando a ser acionado pelo processo.
• O CRM não faz parte deste escopo.

15 · Pendências

Itens que precisam ser confirmados com a Emergency antes da construção. A visita guiada aos processos internos, já acordada na reunião, é o momento natural para fechá-los.

1. Contrato das APIs do ERP — receber a documentação dos endpoints e credenciais de homologação. Viabilidade já considerada resolvida pela premissa 14.1; o que falta é o insumo para configurar o conector.
2. Contrato de acionamento do robô — receber a documentação da interface e o formato de retorno.
3. Volume mensal de pedidos, itens e diligências, para dimensionar licenças e desempenho.
4. Quantidade de usuários por papel: atendentes, expedidores, portadores e financeiro.
5. Percentual de itens resolvidos pelo robô hoje versus os que exigem portador.
6. Política de fundo fixo — existe valor rotativo por portador? Como é reposto hoje?
7. Regra de data de corte — é sempre um dia fixo por cliente ou há variações?
8. Prazos de validade por tipo de certidão, para o subprocesso de monitoramento.
9. Autenticação — há LDAP ou Active Directory, ou o cadastro será próprio do Fluig?
10. SMTP corporativo e domínio de envio das notificações.
11. Papel do e-commerce atual — os pedidos passam a abrir processo no Fluig automaticamente? Decisão sobre Shopify pendente; enquanto isso, a entrada de pedido fica atrás de um endpoint genérico, agnóstico de origem.
12. Escopo do CRM — fora deste escopo pela premissa 14.4; reavaliar em fase posterior.
13. Legal Desk — agenda a marcar, conforme combinado na reunião.
14. Gravação da reunião de 13/07 — liberar acesso para refinar esta especificação com a fala literal.