Integração de dados¶

Uma integração só está concluída quando o processo consegue identificar cada registro, resolver suas referências, interpretar unidade e escopo temporal e explicar o que foi aceito ou rejeitado. Receber um arquivo ou uma requisição não prova que os dados se tornaram utilizáveis.

Quatro famílias conectadas¶

As famílias formam uma cadeia de dependências. Uma venda referencia material, location, data e unidade. Um Demand Plan referencia configuração e histórico. Um Supply Plan referencia demanda, malha, políticas e perfil.

Contrato de uma base¶

Cada página publicada deve responder:

1. Caminho em Data: onde o planejador acessa a base.
2. Finalidade: qual decisão a consome.
3. Granularidade: o que uma linha representa.
4. Chave: como a linha é identificada de forma única.
5. Campos obrigatórios: valores que precisam ser informados e não possuem default.
6. Campos opcionais: valores que podem ser omitidos e, somente para eles, o valor padrão se não preenchido.
7. Referências: cadastros que precisam existir antes.
8. Valores enumerados: payloads exatos em inglês e seus significados.
9. Dependências e utilizado por: requisitos upstream e consumidores downstream.
10. Validação e reconciliação: como provar completude e coerência.

Valores padrão pertencem somente a campos opcionais. Um identificador obrigatório nunca recebe default inventado.

Ordem recomendada de preparação¶

1. Crie identificadores estáveis de material, location e unidade.
2. Carregue conversões e características de planejamento.
3. Carregue dados mestres de malha, produção e economia.
4. Carregue vendas, estoque e ordens abertas.
5. Configure clusters, perfis, workflows e políticas.
6. Reconcilie contagens, quantidades, cobertura e referências.
7. Execute um plano pequeno e controlado.
8. Compare o plano gerado com totais conhecidos antes de ampliar o escopo.

A sequência exata depende do workflow. Demand Planning começa em Preparar os dados; Supply Planning segue o modelo físico.

Tempo e calendário¶

Para cada base temporal, defina:

• fuso do negócio;
• significado da data: ocorrência, documento, expedição, recebimento, disponibilidade ou fim do período;
• corte inclusivo ou exclusivo;
• regra de bucket diário, semanal ou mensal;
• política de período fechado e dado atrasado;
• correção e recarga histórica.

Não agregue em buckets antes de acordar o significado da data. Expedição e recebimento podem cair em períodos diferentes por causa do lead time.

Unidades e quantidades¶

Toda quantidade precisa ser interpretável por unidade declarada ou default governado. Conversões são específicas por material quando a relação de negócio depende do item. Conversão ausente é erro de validação, não permissão para misturar unidades.

A reconciliação compara totais da fonte e aceitos na unidade original e na unidade de planejamento. Valores econômicos também exigem moeda, data de valoração e interpretação bruta ou líquida explícitas quando aplicável.

Chaves, atualizações e duplicidades¶

O identificador da fonte pode ser um ID transacional natural ou uma concatenação estável de elementos como data, material e location. A regra permanece estável entre cargas.

Antes de escolher substituição, merge ou append, documente:

• chave única e política de duplicidade;
• se uma chave repetida atualiza ou rejeita;
• como cancelamentos e correções são representados;
• impacto de recarga histórica em planos já liberados;
• se ausência na fonte significa exclusão ou apenas ausência de novo evento.

Retry e duplicidade no transporte são contratos versionados de API ou arquivo. Não os deduza apenas da chave de negócio.

Camadas de validação¶

Validação estrutural¶

Verifica colunas obrigatórias, tipos, enums exatos e datas e números interpretáveis.

Validação referencial¶

Confirma materiais, locations, unidades, perfis, versões de malha e demais referências.

Validação de negócio¶

Verifica sinais de quantidade, vigências, rotas elegíveis, consistência produtiva, calendário e outras regras do domínio.

Reconciliação¶

Compara linhas recebidas, aceitas, rejeitadas, atualizadas e inalteradas, além de totais por período e dimensão. Resposta HTTP de sucesso ou task concluída não bastam.

Contrato de erro¶

Uma rejeição acionável identifica base, chave ou linha, campo, valor recebido, regra violada e ação corretiva. Imports em lote preservam o resumo aceito/rejeitado e tornam explícita qualquer aceitação parcial.

Nunca esconda dado financeiro ou conversão inválida com zero. Zero só é valor de negócio quando o contrato o define assim.

Checklist operacional¶

• responsáveis pela fonte e planejamento identificados;
• corte, cadência, fuso e nível de serviço acordados;
• versão do schema e enums controlados;
• credenciais e secrets fora de arquivos e logs;
• referências carregadas antes dos fatos dependentes;
• restart e retry testados;
• linhas e quantidades reconciliadas;
• plano controlado valida o consumo downstream;
• monitoramento detecta cargas atrasadas, vazias, duplicadas ou anormalmente grandes.

Limite de versão¶

Layouts, endpoints, autenticação, paginação, retry e semântica de transporte devem ser publicados junto da versão executável. O catálogo descreve o significado durável; a documentação da release fornece o contrato exato de transporte.

Continue em Arquitetura, no catálogo de dados ou no primeiro workflow Community.