Aula 2 - Análise e Carga de Dados

Módulo 7 · Sistemas de Informação · Semana 3 · Aula 2

Análise e Carga de Dados

Análise e preparação de dados para carga no SAP: da planilha do sistema legado ao arquivo aceito pelo objeto de migração

Sistemas de Gestão e Governança Empresarial · Prof. Afonso Brandão · 18/08/2026

Objetos de migração

Perfilagem e qualidade

Transformação em pandas

Reconciliação e cutover

⏱️ Daily — 15 Minutos

O que você fez? O que vai fazer? Algum impedimento?

15:00

✅ O que fiz 🎯 O que vou fazer 🚧 Impedimentos 📦 Progresso do projeto

Agenda

Dois tempos de aula, quatro blocos — o terceiro executado no Google Colab

Bloco 1 — Migração na implantação (30 min)

Por que a migração de dados concentra risco de cronograma; objetos de migração e critério de corte; ferramentas de carga do SAP; anatomia do template de migração.

Bloco 2 — Perfilagem e qualidade (35 min)

Dimensões de qualidade; medidas de perfilagem; conformidade técnica dos campos; domínios de configuração, duplicidade e integridade referencial.

Bloco 3 — Prática no Colab (40 min)

Ingestão da planilha legada com múltiplas abas, transformações canônicas, quarentena dos registros rejeitados e emissão do arquivo de carga.

Bloco 4 — Aceite e cutover (15 min)

Reconciliação por totais de controle; ensaios de carga; tratamento de erros e reexecução; governança dos dados e proteção de dados pessoais.

Objetivo de aprendizagem: ao final da aula o estudante deve ser capaz de perfilar uma base legada em planilha, especificar e aplicar em Python as regras de limpeza, padronização e validação exigidas pelo objeto de migração do SAP, e emitir o arquivo de carga acompanhado do relatório de exceções e da reconciliação de totais.

1. Onde a implantação atrasa

A carga de dados é executada no fim do cronograma e depende de trabalho que começa no início

Sintomas recorrentes

A base legada só é examinada quando o ambiente de destino já está configurado.
O arquivo de carga é rejeitado por formato antes de qualquer validação de negócio.
Registros essenciais falham por depender de cadastro ainda não migrado.
O número de registros que deveriam ter sido carregados não está declarado.

Consequências

Ciclos de correção manual em planilha, sem registro do que foi alterado.
Divergência entre o saldo do sistema legado e o do sistema novo.
Cutover estendido além da janela acordada com a operação.
Dados incorretos em produção, com custo de correção superior ao da prevenção.

A migração constitui trabalho de análise de dados, iniciado antes da virada, que produz três artefatos verificáveis: o arquivo de carga, o relatório de exceções e a reconciliação de totais. A ausência de qualquer um deles impede afirmar que a carga foi bem-sucedida.

2. O ciclo da migração de dados

Sete etapas, iteradas a cada ensaio de carga

flowchart LR A[Extração
do legado] --> B[Perfilagem
diagnóstico] B --> C[Limpeza e
enriquecimento] C --> D[Mapeamento
de-para] D --> E[Transformação
ao layout SAP] E --> F[Carga
no ambiente] F --> G[Reconciliação
e aceite] G -.->|exceções| C

Etapas 1 e 2

Executadas fora do SAP, sobre o extrato do sistema legado. Produzem o diagnóstico quantitativo da base.

Etapas 3 a 5

Objeto desta aula. Implementadas como código versionado e reexecutável.

Etapas 6 e 7

Executadas no ambiente de destino. Devolvem exceções que realimentam a etapa 3.

RM-01 Toda transformação aplicada à base legada deve ser reexecutável a partir do extrato original. Correção manual no arquivo de carga, sem alteração correspondente no código, constitui perda de rastreabilidade.

3. Escopo: o que se migra

Objetos de migração e critério de corte

Dados mestres

Plano de contas e centros de custo.
Parceiro de negócios: cliente e fornecedor.
Material, com dados gerais e dados por centro.
Listas técnicas, condições de preço e tabelas de imposto.

Migram-se os registros ativos. Cadastro sem movimento no período definido é candidato a descarte, com decisão registrada.

Dados transacionais

Saldos de estoque por material e centro.
Títulos em aberto a receber e a pagar.
Pedidos de compra e de venda em aberto.
Saldos contábeis de abertura.

Migram-se as posições em aberto; o histórico completo permanece consultável no sistema legado ou em repositório analítico.

O escopo é decisão de negócio com consequência técnica direta: cada objeto adicionado ao escopo acrescenta um ciclo completo de perfilagem, transformação, ensaio e reconciliação. A ampliação de escopo sem revisão de cronograma é causa frequente de atraso no cutover.

4. Ferramentas de carga do SAP

A escolha condiciona o formato exigido do arquivo

Recurso	Uso previsto	Entrada esperada
Migration Cockpit Migrate Your Data	Instrumento padrão de migração no S/4HANA, com objetos pré-configurados por área.	Planilha no modelo publicado pelo próprio objeto, ou tabelas de preparação alimentadas por carga externa.
BAPI e interfaces de serviço	Cargas recorrentes ou integração contínua com sistema externo.	Estrutura de parâmetros da interface, alimentada por programa.
IDoc	Troca assíncrona de documentos entre sistemas.	Mensagem estruturada com segmentos e campos definidos.
Entrada manual assistida	Volumes residuais e cadastros de exceção.	Digitação com conferência dupla.

Qualquer que seja o instrumento, o requisito para esta aula é o mesmo: entregar um conjunto de registros que satisfaça, antes da carga, as regras de formato, de domínio e de dependência do objeto de destino. O trabalho de preparação é independente da ferramenta escolhida.

Verificação obrigatória no projeto: confirmar, com o parceiro, a versão do produto e o instrumento de carga homologado antes de definir o layout de saída. O modelo de planilha varia entre versões e entre modos de implantação.

5. Anatomia do modelo de carga

O objeto de migração publica a especificação que o arquivo deve satisfazer

O que o modelo declara

Uma aba por estrutura do objeto — dados gerais, textos, dados por centro.
Nome técnico do campo, além do rótulo em linguagem de negócio.
Obrigatoriedade: campo-chave, obrigatório ou opcional.
Tipo, comprimento máximo e formato esperado.

Consequências para o código

A leitura da planilha legada é feita com todas as colunas como texto, para preservar zeros à esquerda.
Cada aba do modelo corresponde a um DataFrame distinto, ligado pela chave do objeto.
O cabeçalho do modelo é preservado; os dados são escritos abaixo dele.
Campo obrigatório ausente constitui erro do registro.

O número da linha em que os dados começam varia conforme a versão do modelo. Localize-a programaticamente pela linha que contém os nomes técnicos dos campos, em vez de fixar um valor no código.

RM-02 É obrigatório que a estrutura do arquivo de carga seja derivada do modelo publicado pelo objeto de migração da versão em uso, e não de exemplo obtido de outra fonte.

6. Dimensões de qualidade de dados

Cada dimensão corresponde a uma verificação programável

Dimensão	Pergunta que responde	Verificação no caso da distribuidora
Completude	Os campos obrigatórios estão preenchidos?	Material sem unidade de medida básica.
Unicidade	Cada objeto do mundo real aparece uma única vez?	Mesmo material cadastrado com dois códigos.
Validade	O valor pertence ao domínio admitido?	Grupo de mercadorias inexistente na configuração.
Consistência	Os valores concordam entre si e entre fontes?	Peso bruto inferior ao peso líquido.
Acurácia	O valor corresponde ao fato do mundo real?	Estoque divergente da contagem física.
Integridade referencial	As referências apontam para registros existentes?	Estoque em centro ainda não cadastrado.

Completude, unicidade, validade, consistência e integridade referencial são verificáveis por código sobre a própria base. A acurácia exige confronto com a realidade — inventário físico, confirmação com o cliente, extrato bancário — e não é decidível na planilha.

7. Perfilagem: o diagnóstico antes da correção

O que medir em cada coluna antes de escrever qualquer transformação

Medidas por coluna

Contagem de vazios e de valores em branco textual.
Cardinalidade: quantidade de valores distintos.
Distribuição dos valores mais frequentes.
Comprimento mínimo, máximo e médio.

Medidas por padrão

Conformidade a expressão regular esperada.
Presença de caracteres de controle e espaços duplicados.
Mistura de tipos na mesma coluna.
Valores fora de faixa e sentinelas como 0, -1, N/A.

Medidas por registro

Duplicidade pela chave natural.
Duplicidade aproximada por descrição normalizada.
Registros órfãos em relação a outra aba.
Registros sem movimento no período de corte.

Produto da perfilagem

Quantificação de cada defeito.
Lista de decisões pendentes de dono do dado.
Estimativa do esforço de correção.
Linha de base para comparar ensaios sucessivos.

A perfilagem antecede a limpeza. Transformações escritas antes da medição tendem a tratar defeitos presumidos e a omitir os efetivamente presentes.

8. Conformidade técnica dos campos

Regras de formato que a planilha do legado costuma violar

Aspecto	Exigência do destino	Defeito típico do extrato legado
Código com zeros à esquerda	Alinhamento à direita com preenchimento de zeros até o comprimento do campo, para valores puramente numéricos.	A planilha converteu o código em número e eliminou os zeros iniciais.
Data	Armazenamento no formato ano-mês-dia, sem separadores, em campo de data.	Mistura de `dd/mm/aaaa`, texto livre e número serial de planilha.
Decimal	Separador decimal conforme o formato declarado pelo modelo de carga.	Milhar com ponto e decimal com vírgula, no padrão brasileiro.
Unidade de medida	Código constante da tabela de unidades, no idioma de manutenção.	`UN`, `un`, `PÇ`, `peça` e `PC` designando a mesma unidade.
Texto	Comprimento máximo por campo; maiúsculas em campos de chave.	Descrição excedente e espaços duplicados internos.

RM-03 É proibido truncar silenciosamente valor que exceda o comprimento do campo de destino. O registro deve ser encaminhado à quarentena com o motivo declarado, para decisão do responsável pelo dado.

9. Domínios e mapeamento de-para

O valor do legado raramente é o valor aceito pelo destino

Tabela de-para

Estrutura mínima de cada linha do mapeamento:

Valor de origem, exatamente como consta no extrato.
Valor de destino, existente na configuração do ambiente.
Responsável pela decisão e data.
Tratamento do valor não mapeado: rejeitar ou atribuir padrão.

Exemplo — unidade de medida

Origem	Destino	Observação
`UN`, `un`, `PÇ`, `peça`	`PC`	Unidade discreta.
`KG`, `Kg`, `quilo`	`KG`	Massa.
`CX12`	`CX`	Exige fator de conversão declarado.
`—`, vazio	rejeitar	Sem valor padrão admissível.

O mapeamento constitui dado de projeto, versionado junto ao código e mantido fora do corpo do notebook. Valor de origem ausente da tabela deve produzir exceção explícita: atribuição silenciosa de padrão introduz erro que só se manifesta em produção.

10. Duplicidade e registro consolidado

Dois códigos para o mesmo objeto do mundo real

Detecção exata

Coincidência da chave natural após normalização: código, documento fiscal do cliente, par material e centro.

Detecção aproximada

Descrições equivalentes após remoção de acentos, pontuação e espaços redundantes; comparação por similaridade textual.

Consolidação

Escolha do registro que permanece, com critério declarado: maior completude, movimentação mais recente ou decisão do dono do dado.

O que se preserva da consolidação

A tabela de correspondência entre o código descartado e o código mantido é artefato permanente do projeto: documentos históricos, integrações e relatórios do legado continuam a referenciar o código antigo. Sem essa tabela, a rastreabilidade entre os dois sistemas se perde de forma irreversível.

RM-04 É obrigatório que toda consolidação de registros duplicados preserve a correspondência entre o identificador de origem e o identificador mantido no sistema de destino.

11. Dependência e sequência de carga

A ordem de carga decorre de restrição de integridade

flowchart LR CFG[Configuração
centros, depósitos, grupos] --> CTA[Plano de contas
centros de custo] CFG --> BP[Parceiro de negócios
cliente e fornecedor] CFG --> MAT[Material
dados gerais e por centro] MAT --> EST[Saldos
de estoque] BP --> TIT[Títulos
em aberto] CTA --> TIT MAT --> PED[Pedidos
em aberto] BP --> PED

Consequência prática

A validação de integridade referencial de um objeto exige a lista de chaves efetivamente carregadas do objeto antecedente, única a refletir o que existe no ambiente.

Consequência de cronograma

Falha na carga de um objeto antecedente bloqueia todos os dependentes. O ensaio de carga percorre a sequência completa justamente para expor esse encadeamento antes do cutover.

12. Colab — ingestão da planilha legada

Leitura de todas as abas com preservação do texto original

import pandas as pd from google.colab import files enviados = files.upload() # seleciona o .xlsx do legado origem = next(iter(enviados)) # dtype=str preserva zeros à esquerda; keep_default_na=False evita # que 'NA' e 'N/A' virem nulo antes da análise de qualidade. abas = pd.read_excel(origem, sheet_name=None, dtype=str, keep_default_na=False) for nome, df in abas.items(): print(f'{nome:<24} {df.shape[0]:>7} linhas {df.shape[1]:>3} colunas') materiais = abas['Materiais'].copy() estoque = abas['Estoque'].copy()

Função de `dtype=str`

Sem essa instrução, o código 0012345 é lido como o número 12345 e a informação de preenchimento é perdida de forma irrecuperável a partir do extrato.

Função de `keep_default_na=False`

Conversões automáticas de NA e N/A em nulo apagam a distinção entre campo não preenchido e campo preenchido com sentinela — distinção que a perfilagem precisa medir.

13. Colab — perfilagem

Quantificar o defeito antes de corrigi-lo

def perfilar(df): linhas = [] for col in df.columns: s = df[col].astype(str).str.strip() linhas.append({ 'campo': col, 'vazios': int((s == '').sum()), 'distintos': int(s.nunique()), 'compr_max': int(s.str.len().max()), 'exemplo': s[s != ''].head(1).squeeze(), }) return pd.DataFrame(linhas) perfil = perfilar(materiais) display(perfil) # valores distintos de um campo de domínio, por frequência display(materiais['UNIDADE'].str.strip().value_counts())

A tabela de perfil é entregue também ao dono do dado e fundamenta em números a discussão sobre qualidade: quantos registros sem unidade, quantas descrições acima do comprimento admitido, quantos códigos repetidos.

14. Colab — transformações canônicas

Uma função por regra, testável isoladamente

import re, unicodedata def codigo_com_zeros(valor, tamanho=18): """Numérico: zeros à esquerda até o comprimento do campo.""" v = (valor or '').strip().upper() return v.zfill(tamanho) if v.isdigit() else v def texto_limpo(valor): """Colapsa espaços e remove controles; não trunca.""" v = re.sub(r'\s+', ' ', unicodedata.normalize('NFC', valor or '')) return ''.join(c for c in v if unicodedata.category(c)[0] != 'C').strip() def decimal_br(valor): """'1.234,50' -> 1234.50 ; vazio -> None""" v = (valor or '').strip().replace('.', '').replace(',', '.') return float(v) if re.fullmatch(r'-?\d+(\.\d+)?', v) else None materiais['MATNR'] = materiais['CODIGO'].map(codigo_com_zeros) materiais['MAKTX'] = materiais['DESCRICAO'].map(texto_limpo) materiais['BRGEW'] = materiais['PESO_BRUTO'].map(decimal_br)

Cada função recebe um valor e devolve um valor, sem depender do DataFrame. Essa separação permite verificar a regra com poucos casos de teste — inclusive os de fronteira — antes de aplicá-la a toda a base.

15. Colab — validação e quarentena

O registro reprovado segue para a quarentena com o motivo declarado

CENTROS = {'1000', '2000'} # chaves lidas do ambiente de destino def ausente(v): # None, NaN e texto vazio — NaN é truthy! return pd.isna(v) or str(v).strip() == '' def validar(linha): e = [] if ausente(linha['MAKTX']): e.append('descrição ausente') elif len(linha['MAKTX']) > 40: e.append('descrição acima de 40') if ausente(linha['MEINS']): e.append('unidade fora do de-para') if linha['WERKS'] not in CENTROS: e.append('centro inexistente') return '; '.join(e) materiais['erros'] = materiais.apply(validar, axis=1) aprovados = materiais[materiais['erros'] == ''] quarentena = materiais[materiais['erros'] != '']

RM-05 É obrigatório que a soma dos registros aprovados e dos registros em quarentena seja igual ao total lido do extrato. Registro que desaparece entre a leitura e a saída indica defeito na transformação.

A duplicidade é propriedade do conjunto de registros e, por isso, é avaliada à parte, com duplicated. O material traz a validação completa, incluindo pesos, data e o objeto dependente.

16. Colab — emissão do arquivo de carga

Escrita sobre o modelo publicado, com o cabeçalho preservado

from openpyxl import load_workbook wb = load_workbook('modelo_material.xlsx') ws = wb['Basic Data'] for linha in ws.iter_rows(min_row=1, max_row=12): # acha o cabeçalho nomes = [(c.value or '') for c in linha] if 'MATNR' in nomes: col = {v: i for i, v in enumerate(nomes, 1) if v} inicio = linha[0].row + 1 break for n, (_, reg) in enumerate(aprovados.iterrows()): for campo, c in col.items(): if campo in reg: ws.cell(row=inicio + n, column=c, value=reg[campo]) wb.save('carga_material_ensaio1.xlsx') quarentena.to_excel('excecoes_material_ensaio1.xlsx', index=False)

O nome do arquivo identifica o objeto e o ensaio. Arquivos de ensaios sucessivos são preservados: a comparação entre eles demonstra a evolução da qualidade da base e sustenta a decisão de autorizar o cutover.

17. Reconciliação e totais de controle

A carga só é aceita quando origem e destino são confrontados

Totais que se confrontam

Contagem de registros por objeto e por agrupamento relevante.
Somatório dos campos quantitativos: quantidade em estoque, valor de títulos em aberto.
Contagem de valores distintos em campos-chave.
Registros em quarentena, por motivo.

Confronto em pandas

estoque['LABST'] = estoque['QUANTIDADE'].map(decimal_br) estoque['MATNR'] = estoque['CODIGO'].map(codigo_com_zeros) estoque_ok = estoque[estoque['MATNR'].isin(aprovados['MATNR']) & estoque['CENTRO'].isin(CENTROS)] origem = estoque.groupby('CENTRO')['LABST'].sum() destino = estoque_ok.groupby('CENTRO')['LABST'].sum() conf = pd.concat([origem, destino], axis=1, keys=['origem', 'destino']).fillna(0) conf['diferenca'] = conf['destino'] - conf['origem'] display(conf[conf['diferenca'] != 0])

RM-06 É obrigatório que toda divergência de reconciliação seja explicada por registro em quarentena identificado. Divergência sem explicação impede o aceite da carga, ainda que o volume envolvido seja pequeno.

18. Ensaios de carga e cutover

A carga definitiva é a repetição de um procedimento já executado

Ensaio	Propósito	Critério de saída
Primeiro ensaio	Validar o formato do arquivo e expor os defeitos estruturais da base.	Arquivo aceito pelo instrumento de carga; perfil de erros quantificado.
Segundo ensaio	Verificar a eficácia das correções e a integridade entre objetos.	Taxa de rejeição dentro do limite acordado; reconciliação fechada nos objetos principais.
Ensaio final	Reproduzir o procedimento e medir a duração de cada etapa.	Janela de execução compatível com a acordada; plano de retorno testado.
Cutover	Executar a carga com o extrato da data de corte.	Reconciliação assinada pelo dono do dado; autorização de entrada em operação.

A partir da segunda execução, mede-se, além da qualidade dos dados, a duração de cada etapa. A janela de cutover é finita e frequentemente noturna; etapa sem duração medida constitui risco não dimensionado.

19. Governança e antipadrões

Responsabilidade sobre o dado e proteção de dados pessoais

Governança

Cada objeto de migração possui um responsável na área de negócio, que decide sobre exceções e assina a reconciliação.
As decisões de descarte, consolidação e valor padrão são registradas com data e autor.
O código de transformação e as tabelas de-para são versionados junto ao projeto.

Dados pessoais

Extratos com dados pessoais de clientes e empregados exigem base legal e controle de acesso — inclusive fora do sistema, em planilhas e notebooks.
Ambientes de ensaio devem utilizar dados descaracterizados sempre que o teste não exigir o valor real.
A retenção dos extratos intermediários é limitada e declarada.

Antipadrões

Corrigir o arquivo de carga à mão, sem alterar o código que o gera.
Atribuir valor padrão a campo obrigatório para eliminar a rejeição.
Migrar o histórico completo por não haver critério de corte definido.
Declarar a carga concluída sem reconciliação com a origem.
Manter o extrato do legado com dados pessoais em pasta pessoal, sem controle de acesso.

20. Atividade — notebook do grupo

Produzida em aula, entregue no repositório do projeto

Roteiro

Escolher um objeto de migração do caso do parceiro.
Obter ou construir o extrato legado em planilha, com pelo menos duas abas relacionadas.
Ingerir com dtype=str e produzir a tabela de perfilagem.
Declarar as regras de transformação, uma função por regra.
Declarar o de-para de pelo menos um campo de domínio.
Validar, separar a quarentena e emitir o arquivo de carga.
Apresentar a reconciliação de contagens e somatórios.

Critérios de aceitação

O notebook executa do início ao fim sem intervenção manual.
Aprovados mais quarentena igualam o total lido.
Todo registro em quarentena possui motivo legível por quem não escreveu o código.
Nenhum valor de domínio é atribuído por omissão.
A reconciliação é apresentada como tabela, com as divergências explicadas.
Os arquivos de saída identificam objeto e ensaio.

Entrega: notebook no Google Colab com acesso concedido ao professor, mais os dois arquivos gerados. O trabalho é insumo direto da aula de testes e cutover no contexto de sistemas empresariais.

Encerramento

Síntese

A preparação de dados para carga é trabalho de análise executado em código reexecutável. Mede-se a base antes de corrigi-la; declara-se cada regra de transformação e cada mapeamento de domínio; encaminha-se à quarentena, com motivo, o registro que não satisfaz o destino; e aceita-se a carga apenas mediante reconciliação com a origem. Nenhum objeto é declarado migrado sem reconciliação com a origem.

Próxima aula: Hands on — Gestão de Configuração e Escopo · 26/08/2026
Módulo 7 · Sistemas de Informação · Aula 2 · Prof. Afonso Brandão

Sobre este encontro

Análise e Carga de Dados · 18/08/2026 · Prof. Afonso

Objetivo de aprendizagem

Ao final do encontro, o estudante deve ser capaz de perfilar uma base legada em planilha, especificar e aplicar em Python as regras de limpeza, padronização e validação exigidas pelo objeto de migração do SAP, e emitir o arquivo de carga acompanhado do relatório de exceções e da reconciliação de totais.

Estratégia do encontro

Exposição dialogada em quatro blocos, cada um seguido da execução imediata do trecho correspondente do notebook no Google Colab sobre uma base legada com defeitos conhecidos; o encontro encerra com a produção, por grupo, do arquivo de carga e do relatório de exceções do objeto de migração escolhido no projeto do parceiro.

Estrutura do encontro

Bloco 1 (30 min) — Migração de dados na implantação: escopo dos objetos, ferramentas de carga do SAP e anatomia do template de migração
Bloco 2 (35 min) — Perfilagem e qualidade: dimensões de qualidade, conformidade técnica dos campos e validação contra domínios de configuração
Bloco 3 (40 min) — Prática em Google Colab: ingestão da planilha multiabas, transformação, quarentena de registros e emissão do arquivo de carga
Bloco 4 (15 min) — Reconciliação, ensaios de carga e cutover: critérios de aceite, tratamento de erros e governança dos dados