Regras de Negócio · FUCHS Fluig

1 · Visão geral

A FUCHS Lubrificantes do Brasil Ltda. gerencia hoje, por e-mail, dois tipos de informação por cliente: documentos de qualidade (laudos, certificados, especificações) e informações de pedido (pedidos de venda em aberto, amostras em andamento). O sistema Fluig substitui esse fluxo manual por um GED organizado por cliente (pasta identificada por CNPJ) com aprovação em nível antes de publicar, e um portal do cliente — construído sobre a API nativa do Fluig — onde o cliente final consulta tudo num único lugar, sem precisar de licença Fluig.

1.1 · Escala da operação

• 6 usuários internos com licença nominal (Qualidade + outras áreas)
• Clientes externos: acessam via portal público, sem consumir licença individual
• 3 tipos de documento mapeados: laudo técnico, certificado de qualidade, especificação de produto
• Sistema integrado: módulo de qualidade do Protheus, onde a FUCHS já mantém documentos com criptografia própria

1.2 · Princípios

• Cliente final NÃO precisa de licença Fluig — acesso via portal público construído sobre a API nativa.
• CNPJ sozinho NUNCA autentica — é validado contra o cadastro de clientes do Protheus e ainda passa por aprovação manual da Qualidade.
• Documento só fica visível ao cliente depois de publicado — mesmo estando na pasta dele, enquanto aguarda aprovação ele não aparece.
• Notificação por e-mail e na plataforma — sem WhatsApp.
• Sem assinatura eletrônica no MVP — não há fluxo de assinatura neste escopo (documentos são consultivos, não contratuais).

1.3 · 3 fases do processo

2 · Glossário

3 · Atores e papéis

4 · Modelo de dados

4.1 · Entidades principais

Cliente (identificado por CNPJ)
  ├── Pasta no GED
  │     └── Documento (N)
  │           ├── Versões / revisões
  │           ├── Metadados (tipo, validade, marca d'água, notificação)
  │           └── Aprovação em nível (0 ou N aprovadores)
  ├── Pedidos de venda (N) — sincronizados do Protheus
  └── Amostras em andamento (N) — sincronizadas do Protheus

Usuário interno FUCHS (nominal)
  └── Papel (Qualidade / Gerente Técnico / Administrativo)

Cliente

• cnpj (PK), razao_social, responsavel_nome, responsavel_email, acesso_status (pendente|aprovado|recusado), acesso_liberado_em

Documento

• id (PK), cliente_cnpj (FK), tipo (laudo|certificado|especificacao), titulo, versao, revisao, validade_inicio, validade_fim, marca_dagua (bool), permite_download (bool), notificar_cliente (bool), requer_aprovacao (bool), status (rascunho|aguardando_aprovacao|publicado|reprovado), publicado_em

Aprovação

• documento_id (FK), aprovador_papel, decisao (aprovado|reprovado), motivo_reprovacao, decidido_em, prazo_limite (P3D a partir da entrada na fila)

Pedido de venda (sincronizado)

• numero_pedido (PK), cliente_cnpj (FK), produto, quantidade, status (producao|transporte|faturado), previsao_entrega

Amostra (sincronizada)

• numero_amostra (PK), cliente_cnpj (FK), produto, status (analise|enviada), solicitado_em

5 · Regras de negócio por fase

5.1 · Fase 1 · Onboarding do cliente

RN-1.1 · Pré-cadastro

• Cliente informa CNPJ, nome e e-mail do responsável — sem exigir licença Fluig.
• CNPJ sozinho NÃO concede acesso — é só o identificador do pré-cadastro.

RN-1.2 · Validação contra o Protheus

• Service Task confronta o CNPJ informado com o cadastro de clientes do Protheus (SA1) via API nativa do Fluig.
• CNPJ não encontrado: cliente é avisado e pode corrigir os dados — loop de correção sem abrir novo chamado.
• Falha técnica na integração (Protheus indisponível): cai em diagnóstico técnico e reenvia automaticamente após corrigir (Boundary Error Event).

RN-1.3 · Aprovação de acesso

• Mesmo com CNPJ validado, a Qualidade FUCHS confirma manualmente a liberação — controle humano final.
• Boundary Timer não-interrompente (PT24H): sem decisão em 24h, dispara lembrete automático sem cancelar a tarefa.
• Aprovado o acesso, credenciais são enviadas automaticamente por e-mail ao responsável indicado.

5.2 · Fase 2 · Documento de qualidade

RN-2.1 · Anexar documento

• Documento é anexado na pasta do cliente correto (identificada por CNPJ) — nunca solto fora de uma pasta.
• Tipo obrigatório: laudo técnico, certificado de qualidade ou especificação de produto.
• Controle de versão/revisão nativo do GED — cada atualização registra quem mudou, quando e o quê.
• Validade pode ter início futuro ("válido a partir de") — documento fica invisível pro cliente até a data configurada.
• Marca d'água configurável sem programação (texto, ângulo, posição).

RN-2.2 · Aprovação em nível

• Nem todo documento requer aprovação — configurável por documento (não fixo por tipo).
• Especificação de produto vai pro papel gerente-tecnico-fuchs; laudo e certificado vão pro papel qualidade-fuchs — alçada por tipo de documento.
• Prazo de 3 dias (P3D, interrompente): sem decisão no prazo, documento volta automaticamente pra qualidade corrigir.
• Reprovação exige motivo preenchido — vira pendência pra correção antes de reenviar.

RN-2.3 · Publicação e notificação

• Documento aprovado (ou que não requeria aprovação) é publicado no GED e o cliente é notificado por e-mail + plataforma.
• Notificação pode ser desligada por documento (ex.: publicações que não precisam de aviso imediato).
• Falha na publicação/notificação cai em diagnóstico técnico e é reenviada automaticamente (Boundary Error Event).

5.3 · Fase 3 · Consumo no portal

RN-3.1 · Consulta do cliente

• Cliente vê apenas documentos publicados da própria pasta — nunca de outros clientes.
• Documentos aguardando aprovação NÃO aparecem, mesmo que já estejam na pasta.
• Portal mostra também pedidos de venda em aberto e amostras em andamento, vindos do Protheus.

RN-3.2 · Sincronização periódica

• Subprocesso collapsed consulta periodicamente o Protheus por pedidos e amostras do cliente, mantendo o portal atualizado sem ação manual.

6 · Eventos / timers

7 · Validações

7.1 · Pré-cadastro do cliente

• CNPJ deve passar pelo algoritmo de validação oficial (dígitos verificadores).
• CNPJ deve existir no cadastro de clientes do Protheus (SA1) e estar ativo.
• E-mail do responsável obrigatório e validado por formato.

7.2 · Documento

• Cliente (pasta), tipo de documento e título são obrigatórios.
• Validade fim, se preenchida, deve ser posterior à validade início.
• Reprovação exige motivo preenchido.

8 · Integrações

Pendência: a versão do Protheus instalada e o padrão de integração disponível (REST nativo, JCo, ou middleware próprio) precisam ser confirmados com a TI da FUCHS antes de dimensionar o esforço de integração no Works.

9 · Notificações

10 · Datasets Fluig necessários

11 · Parâmetros configuráveis

12 · Permissões e papéis

13 · Cenários comerciais

A FUCHS pediu explicitamente a proposta separada em cenários, pra decidir internamente antes de levar à diretoria. Este protótipo tangibiliza o Cenário 1 — o mais completo e o que mais demonstra o valor da plataforma.

13.1 · Cenário 1 · Fluig + GED + Portal + Integração completa

• Documentos de qualidade migram (ou são replicados) pro GED do Fluig — versionamento, aprovação em nível, marca d'água, rastreio de leitura e busca por conteúdo nativos.
• Portal do cliente consulta o GED Fluig diretamente.
• Integração com o Protheus alimenta pedidos e amostras no portal, e pode confrontar/importar documentos do módulo de qualidade.
• É o cenário demonstrado neste protótipo.

13.2 · Cenário 2 · Apenas o portal

• Documentos de qualidade permanecem no Protheus — inclusive com a criptografia própria que a FUCHS já usa no módulo de qualidade.
• O portal do cliente é construído da mesma forma (login único via API nativa do Fluig), mas busca os documentos diretamente no Protheus em vez do GED.
• Reduz o escopo de migração de conteúdo, mas mantém a administração de documentos descentralizada (sem os benefícios de GED como pastas por cliente, aprovação em nível e indexação por conteúdo).
• Elegível quando a FUCHS decidir não migrar o acervo de documentos de qualidade pro Fluig no primeiro momento.

13.3 · On-premises vs. cloud TOTVS

Requisitos mínimos detalhados de cada modalidade (CPU, memória, licenciamento) devem ser levantados pela equipe técnica TOTVS antes de fechar a proposta comercial — fora do escopo deste protótipo de tangibilização.

14 · Requisitos não-funcionais

• Performance: portal do cliente carrega em < 2s · sincronização com Protheus roda em segundo plano.
• Auditoria: rastreio de leitura nativo do GED — quem viu qual documento, quando e quantas vezes.
• Licenciamento: nominal, 6 usuários internos (Qualidade + outras áreas). Clientes externos não consomem licença.
• LGPD: dados de CNPJ e responsável ficam restritos ao pré-cadastro do próprio cliente · log de acessos.
• Idiomas: Fluig suporta PT-BR, EN e ES nativamente — avaliar necessidade conforme carteira de clientes da FUCHS.
• Browser: Chrome, Edge, Firefox últimas 2 versões.

15 · Pendências pra fechar escopo

1. Versão do Protheus instalada e padrão de integração disponível (REST nativo, JCo, ou middleware próprio).
2. Decisão entre Cenário 1 e Cenário 2 — migrar documentos pro GED ou manter no Protheus.
3. Decisão entre on-premises e cloud TOTVS — afeta responsabilidade de backup/atualização e requisitos de infraestrutura.
4. Nível de acesso ao módulo de qualidade do Protheus — como o Fluig vai autenticar/descriptografar documentos que permanecerem lá (Cenário 2).
5. Lista de tipos de documento definitiva — confirmar com a FUCHS se laudo/certificado/especificação cobrem todos os casos, ou se há subtipos (ex.: por linha de produto).
6. Alçada de aprovação por tipo de documento — confirmar se especificação de produto realmente exige gerência técnica, ou se todos os tipos usam o mesmo papel de aprovação.
7. Volume estimado de clientes com acesso ao portal — não impacta licenciamento Fluig, mas ajuda a dimensionar a infraestrutura.