Sabedoria da estratégia de conversão de dados
estratégia de conversão de dados
Conversão de dados no projeto SAP & # 8211; conversão do sistema herdado para SAP ECC.
Gostaria de compartilhar minha experiência no processo de conversão de dados com a comunidade SAP. A conversão de dados é um dos processos mais críticos em projetos de implementação de SAP bem-sucedidos. Este processo é uma parte da etapa de realização no & # 8220; ASAP & # 8221; metodologia (etapa 1: preparação do projeto, etapa 2: plano. etapa 3: realização. Etapa 4: preparação final. Etapa 5: ir ao vivo). Os consultores SAP e implementadores locais geralmente são responsáveis por realizar a conversão de dados do sistema herdado para o SAP ECC. Também ouvi falar de projetos SAP em que a equipe Basis realizou esse processo.
Os dados convertidos são usados apenas para configurar dados mestre no ECC. não é usado para configurar os dados transacionais históricos do sistema herdado.
Existem diferentes ferramentas que convertem dados: 1. SAP ECC construído na ferramenta via código de transação LSMW. 2. Ferramenta externa chamada Corredor de processo que se comunica facilmente com o ECC. Eu usei o Runner Process que foi comprado pela minha empresa.
Duas das qualidades mais importantes que são necessárias para ter sucesso nesse processo são: 1. Absorção 2. Comunicando & amp; entendendo as necessidades do seu Cliente.
Como mencionado acima, o processo de conversão de dados faz parte do passo de realização. O passo de realização começa depois que os conselheiros (ou implementadores locais) terminaram de escrever e enviando os documentos do modelo para a aprovação do cliente. Após a aprovação, os implementadores começam a personalizar e anotar documentos de especificação para novos desenvolvimentos na área de Desenvolvimento na ECC. Só então, é possível iniciar o processo de conversão de dados.
Existem sub passos nas conversões de dados:
1. Mapeando os campos necessários no objeto ECC que será preenchido com dados (I. E: objeto do equipamento no módulo PM)
Aqui você precisa estar bem ciente do que está escrito nos documentos do modelo em relação aos seus objetos SAP.
É recomendável diferenciar entre campos obrigatórios de valor deste objeto e valor de campos não obrigatórios. Algumas vezes a classificação do objeto é necessária. Isso acontece quando os campos regulares do objeto não são suficientes para armazenar dados inteiros do sistema antigo. Eu usei classificação em equipamento objeto que representava geradores elétricos.
O objetivo deste passo é verificar se o implementador é capaz de criar dados mestre manualmente antes de realizar a gravação.
3. Gravando dados mestre configurados através do Process Runner (ou LSMW).
Caso a gravação não seja precisa, ou as mudanças na configuração dos dados mestre devem ser feitas após a gravação, a gravação deve começar tudo de novo. Assim, é importante para você ter certeza de como configurar os dados mestre dos objetos corretamente. No caso de a gravação ser precisa e você salvou, o Runner de processo cria um arquivo EXCEL com as colunas apropriadas a serem preenchidas (de acordo com os campos que você inseriu na gravação) para configurar várias instâncias automaticamente.
Por exemplo: Você gravou a configuração de dados mestre de uma peça de equipamento com determinados dados. Depois de salvar a gravação, o corretor de processo criará a estrutura adequada em EXCEL para futuras gravações. Então, você poderá preencher as colunas corretas do arquivo EXCEL com tantas peças de dados do equipamento, conforme necessário, e executar a gravação novamente quando desejar configurar essas peças. Desta forma, múltiplos equipamentos serão criados através do Process Runner.
4. Criando programa de extração para extrair dados do sistema antigo.
Nesta etapa você precisa especificar para o administrador do sistema legado (ele geralmente é um programador MF) de maneira precisa quais os campos e quais tabelas você precisa dos dados. A segunda coisa que você precisa considerar: qual é a população de dados a ser extraída (I. E: somente peças / equipamentos ativos que foram criados após determinada data. Seu cliente saberá as respostas para esta questão). O administrador do sistema deve então preparar o programa no sistema herdado para uso futuro. No meu projeto, o sistema legado era o sistema MF que estava escrito em ADABAS NATURAL. Enviei documentos de especificação ao administrador especificando campos para extrair e qual a população de dados a extrair.
Se houver necessidade de fazer algum tipo de manipulação de dados (IE: 1. O tipo de equipamento no legado contém valores: A, B, C, enquanto o tipo de equipamento ECC foi personalizado para conter valores AA, BB, CC, respectivamente 2. alteração do formato dos valores da data etc.), o administrador deve codificá-lo no programa.
É muito aconselhável que este programa classifique as colunas de saída de forma idêntica à ordem das colunas no arquivo EXCEL da etapa anterior. O administrador deve classificar as colunas da maneira correta. Eventualmente, o programa de extração cria o arquivo EXCEL cheio de dados de extração que se encaixa na estrutura de arquivos EXCEL e no formato da etapa anterior.
5. Analisando arquivos de log de erros e fixando o programa de extração.
Nesta etapa, o arquivo EXCEL está cheio de dados a serem carregados no SAP ECC. tente carregar 50% de todas as linhas no arquivo. Runner de processo criará resultados de saída. Se houver algum erro enquanto o programa está tentando criar dados mestres, ele indicará os motivos para isso. Você deve analisar e corrigir o programa, respectivamente.
6. Preparando o programa de eliminação e arquivamento no SAP ECC.
Eventualmente, há uma chance de você precisar excluir qualquer um dos dados que foram carregados por qualquer motivo. Então, primeiro, você precisará distinguir os dados que foram convertidos e carregados na área SAP ECC de outros dados criados manualmente pelos usuários. A melhor maneira de fazê-lo é usar o relatório padrão SAP e especificar na tela de seleção do relatório o usuário SAP que criou os dados. Por exemplo, no meu projeto, um determinado programador estava usando o Runner de processo para carregar os dados. Todos os dados que ele carregou foram criados sob seu código de usuário. Assim, foi fácil distinguir os dados. Depois que o relatório extraiu esses dados, marque o que é necessário para a exclusão e use o código SARA para arquivar os dados (publicarei um guia específico separado para arquivar dados em SAP usando o tato SARA).
Espero que esta informação o ajude a trabalhar com o SAP. Para qualquer dúvida sobre este processo preencha-me para me perguntar.
4 Comentários.
Você deve estar conectado para comentar ou responder a uma postagem.
Nunca compartilhe suas informações pessoais no fórum público. Se você quiser compartilhar suas informações pessoais, fique visível em seu perfil e diga ao outro usuário que leve as informações do seu perfil.
Nunca publique essas informações em discussão / blog / documento.
Daniel Gontar Post author 16 de agosto de 2014 às 13h40.
Cheguei a bordo de um projeto bastante ad-hoc durante uma fase de conversão e devo dizer que esta publicação no blog foi uma introdução muito boa às conversões.
estratégia de conversão de dados
Este documento fornece um procedimento para ajudá-lo a organizar e executar a transferência de dados do sistema herdado.
Ele descreve uma metodologia para migração de dados que usei com sucesso em diferentes implementações. Baseia-se nas minhas experiências anteriores. Não há garantia sobre o conteúdo ou sobre os resultados. Este guia oferece sugestões. Cabe a você seguir as dicas e criar sua própria metodologia.
Terminologia comum e abreviaturas em projetos de migração:
Nota: Os termos SAP e R / 3 são ambos utilizados de forma intercambiável para se referir ao sistema SAP R / 3.
Big Five: quando se refere aos Big Five, significa Mestre de Materiais, Mestre de Clientes, Mestre de Fornecedores, Lista de Materiais (BOM) e Roteiros.
Objetos comerciais: para ajudar no processo de análise e transferência, os dados não são tratados como tabelas ou conteúdo de campo, mas sim como objetos em termos de negócios operacionais. Estes são chamados Business Objects.
Business Object DC responsável: responsável pelo processo de conversão (fonte de dados legados e integridade, mapeamento, regras de conversão, etc.) e pelo respeito da programação planejada para o objeto comercial.
Proprietário do objeto de negócios: aquele que possui a informação no negócio do cotidiano. Esta é a pessoa que irá fazer as escolhas estratégicas sobre requisitos funcionais para o objeto de negócios e que fará a validação final dos dados convertidos. Pode ser identificado ao encontrar a pessoa hierárquica mais alta que será diretamente e principalmente afetada se o objeto de negócios não funcionar & rdquo;
Conversão de dados e amp; Migração de dados: o processo de conversão de dados. & # 8220; Conversão de dados & rdquo; e & # 8220; Data Migration & rdquo; Os termos são usados indistintamente no documento.
DC: Abreviação do processo de conversão de dados.
Domínio: domínio funcional dentro do projeto, como Finanças, Vendas, Produção, etc.
Arquivo plano: um formato de arquivo usado para importar dados para o SAP. O arquivo plano é um arquivo de texto simples com um separador de separadores entre campos. Pode ser facilmente gerado a partir do Excel ou Acesso.
Arquivo intermediário: um Excel, acesso ou outro tipo de arquivo, que é manipulado manualmente em um processo entre a extração LS e a geração de arquivos planos.
LSMW: Legacy System Migration Workbench. É uma ferramenta SAP para conversão que permite o carregamento de dados usando arquivos planos extraídos do Sistema Legado.
Tabela de referência cruzada ou tabela X-Ref: Uma tabela que mostra a relação entre campos quando um valor está relacionado a um campo pai. Por exemplo, a & # 8220; Organização de vendas & # 8221; será configurado de acordo com o tipo de material.
WBS: estrutura de repartição do trabalho.
Implementar o SAP é um desafio importante, tanto em termos de recursos (pessoas, dinheiro, tempo) como em processos comerciais. Muito está em jogo e, para a maioria de vocês, o fracasso não é uma opção que você pode pagar. Para colocar todas as probabilidades do seu lado, você precisa de uma boa metodologia. Um que irá fornecer-lhe um planejamento realista, uma organização sólida, uma maneira de gerenciar o processo e ferramentas de controle para detectar e corrigir o deslizamento antes que ele se torne um problema.
Antes mesmo de começar a trabalhar em especificações, você deve primeiro se organizar. Obter uma boa estrutura de planejamento e organização leva cerca de duas semanas para o primeiro rascunho, o que o deixará com algumas questões sobre a organização do projeto. Obter um planejamento completo e final levará pelo menos mais uma semana. Qualquer problema não resolvido sobre estes irá assombrá-lo durante todo o projeto, então termine isso completamente antes de indicar qualquer outro passo.
A conversão de dados requer recursos funcionais e técnicos da maioria dos departamentos. Estes mesmos recursos provavelmente estarão envolvidos em outra parte do projeto. Por esta razão, o risco de uma tarefa conflitante é alto e pode levar rapidamente a um gargalo onde os povos-chave estão sobrecarregados. Por esse motivo, você deve considerar a conversão de dados como um projeto dentro do projeto. Isso se traduz na preparação de um plano de conversão completo que o ajudará a passar pelo processo e permitirá prever e resolver o uso de recursos em conflito antes do gargalo que já ocorreu.
Os principais passos da conversão de dados são:
Organização da conversão de dados (Gerente de projeto e coordenador de conversão de dados)
Plano de conversão de dados O WBS com estimativa de carga de trabalho O planejamento do calendário com o carregamento de recursos.
Iniciando com a conversão de dados do Business Objects (O recurso responsável pelo Business Object DC)
Data Purging and Cleansing Mapeamento e regras de conversão Extrair e carregar programas de regras Adaptação de dados e regras (regras de ajuste e programas após o teste) Teste de unidade de carga (teste unitário e pequeno volume de dados manuais) Extração e carga Testes de tamanho completo (dados teste e validação / grande volume com dados extraídos de verdade) carregamento de dados completos no sistema de aceitação carregamento completo de dados no sistema de produção prévia Validação de dados convertidos e Key User + Business Objects Inscrição do proprietário Conversão completa em SYSTEME DE PRODUÇÃO e sinalização final.
Plano de conversão de dados.
Objetos empresariais.
Um objeto de negócios é uma categoria geral para dados que define algo como mestre de material, mestre de fornecedores, ações, pedidos, requisições de compra ou unidades organizacionais. O primeiro passo é identificar quais objetos comerciais (Objetos) são necessários na sua implementação SAP.
Existem três tipos de dados envolvidos em um sistema SAP: dados mestre, dados transacionais e dados históricos.
Dados mestre. Os dados mestre de aplicativos tendem a ser mais estáticos, uma vez definidos. A maioria dos dados mestre pode ser conduzida pelas aplicações legadas. Os exemplos incluem fornecedores, clientes, gráficos de contas, ativos, contas de materiais, mestres de materiais, registros de informações, e assim por diante. Dados Transacionais. Os dados transacionais são dados de transações atuais e pendentes que precisam ser capturados pelo sistema antigo e definidos para os aplicativos SAP R / 3 para a conclusão do processo comercial. Exemplos incluem documentos contábeis, ordens de compra abertas, ordens de vendas abertas, pedidos atrasados e assim por diante. Data histórica. Os dados históricos precisam ser transferidos do sistema herdado para o sistema SAP R / 3 para fins de referência. Os exemplos incluem pedidos de compra fechados, ordens de vendas fechadas, informações gerais do resumo, e assim por diante.
Informações para completar o plano de conversão.
O que objetos de negócios serão convertidos do sistema herdado para o SAP. Onde onde estão os dados, quais sistemas Legacy estão envolvidos para a extração. Quanto estimar o número de registros a serem carregados no SAP. Como há dois aspectos a serem considerados: a forma como os dados são extraídos do Sistema Legado Extraído automaticamente do sistema Legacy sem intervenção manual. Folha de cálculo preenchida manualmente Combinação de uma extração automática do sistema Legacy + Entrada manual em uma planilha A forma como os dados são injetados no SAP: Transferência automática de dados a partir de um arquivo plano para o SAP Inserção manual de dados com transações online para SAP Combinação de ambos.
O método de transferência de dados que você escolherá determinará os tipos de recursos que você precisa. Por exemplo, você pode precisar de funcionários temporários para a entrada manual de dados e programadores para escrever seus próprios programas de extração. Você precisa saber quais são os dados no seu sistema legado e quais aplicativos SAP correspondem aos objetos de negócios que serão transferidos. Uma pessoa não precisa saber tudo isso, mas as pessoas que conhecem essa informação devem trabalhar em estreita colaboração.
Quem é envolvido em cada Objeto de Negócios: Usuário-chave (responsável funcional da conversão BO: Regras, correções de dados manuais, teste, validações) Consultor Responsável pela limpeza e purga de dados no Sistema Legado Responsável pela extração Responsável pelo carregamento de dados no SAP Business Gerenciador de objetos (proprietário hierárquico responsável pelo uso do dia-a-dia e integridade da informação e aquele que será assinado para aceitação de dados)
Main Business Objects seqüência de conversão:
CONVERSANDO UM OBJETO DE NEGÓCIO:
Data Purging and Cleansing.
A purga e limpeza do sistema Legacy irá poupar muito tempo e esforço nas seguintes etapas da conversão. Comece assim o mais rápido possível e faça o máximo possível. Isso pode ser feito sem conhecimento específico do SAP.
Antes de transferir dados do seu sistema antigo, exclua todos os dados antigos e obsoletos. Por exemplo, você pode excluir todos os clientes únicos ou aqueles para os quais não houve transação nos últimos dois anos, também excluir materiais não utilizados.
Este processo corrige inconsistências de dados e garante a integridade dos dados existentes durante o processo de migração. Por exemplo, muitas vezes há muitas inconsistências nos campos de endereços do cliente e do fornecedor. Você encontrará rapidamente que o SAP não permitirá que você carregue nenhum campo de endereço, a menos que você os limpe.
Regras de mapeamento e conversão.
A documentação de cada objeto comercial conterá as regras (ou especificações) de conversão de dados, que incluem:
* Fontes legadas e procedimentos de extração.
De qual sistema (s) Legacy estamos extraindo os dados e como. Documente aqui as etapas específicas que precisam ser tomadas.
Quais são as etapas de limpeza a serem tomadas e os filtros de extração a serem usados.
Diretrizes para aplicar ou regras que são usadas por muitos campos (evitando assim reescrevê-lo e tornar a atualização mais fácil, pois é apenas em um só lugar).
Quais campos SAP usar e como podemos obter o valor final para cada campo SAP.
As regras gerais são aquelas que não se destinam diretamente a um valor de campo. Por exemplo, a forma como diferenciamos os tipos de material no Sistema Legado é uma regra. As regras de campo são aquelas que dão um valor para um campo específico.
Isso é crucial. Ao discutir ou escrever notas, SEMPRE se referir a um campo no formato TABLE-FIELD. Você perceberá rapidamente que, à medida que o projeto vai, diferentes pessoas começarão a usar nomes diferentes para o mesmo campo. Além disso, eles podem começar a usar o mesmo nome para diferentes campos.
Além disso, alguns campos existem em diferentes visualizações nos dados mestre SAP. Algum tempo é o mesmo campo que é mostrado em dois lugares, enquanto outras vezes são realmente dois campos diferentes. A melhor maneira de saber que caso se aplica é ter a informação TABLE + FIELD.
Em Material Master, o campo & # 171; Verificação de disponibilidade & raquo; existe no & # 8220; MRP2 & # 8221; e o & # 8220; Sales Gen & # 8221; pontos de vista. Se você olhar para a TABELA-CAMPO de cada visualização, você obtém:
Sales Gen: MARC-MTVFP.
Em ambos os casos, o nome do TABLE-FIELD é o mesmo, então é o mesmo campo.
Em Customer Master, o campo & # 8221; Termos de pagamento e # 8217; existe em & # 8220; Transações de pagamento & # 8221; e & # 8220; Faturamento & # 8221; pontos de vista. Se você olhar para a TABELA-CAMPO de cada visualização, você obtém:
Transações de pagamento: KNVV-ZTERM.
Exibições de faturamento: KNB1- ZTERM.
Não é o mesmo campo. Na visualização de pagamento, o campo está vinculado ao Código da Empresa, enquanto que para a visualização de Faturamento está vinculado à Organização de Vendas (você encontra isso observando as teclas de tabelas). Portanto, esses dois campos podem ter valores diferentes.
Metodologia Técnica.
Um caso especial para Material Master.
O Mestre de Materiais envolve todos os domínios e pode exigir em qualquer lugar de 20 campos para algumas centenas dependendo da complexidade de sua implementação. Alguns campos serão usados por diferentes domínios, enquanto outros serão usados por um único domínio, mas seu valor terá um impacto na funcionalidade usada por outro domínio.
Este é o Objeto de Negócios mais complexo para documentar e, ao mesmo tempo, é aquele com o qual você deve começar com o processo de conversão.
1º passo: seleção dos campos por cada domínio.
Obtenha cada domínio com seus consultores para passar pelo arquivo de mapeamento e veja os campos para cada tipo de material. O objetivo aqui é ver todos os campos importantes e fazer perguntas para compreendê-los. Isso é feito separadamente por cada domínio e documentado em diferentes arquivos de mapeamento. Nesses pontos, não nos interessa a respeito de onde os valores virão e como os obteremos. APENAS CONSIGUE O MAPEAMENTO E façam a compreensão do que é o mestre do material. Cada vez que um domínio seleciona um campo para um tipo de material específico, eles devem inserir seu tipo de domínio na lista. Aqui estão alguns exemplos (teóricos) de mapeamento de MM, PP e SD.
No Material Master, alguns campos podem ser inseridos / modificados em diferentes visualizações. Por exemplo, o campo & # 8220; Tempo de processamento de recebimento de mercadorias em dias (MARC-WEBAZ) & rdquo; existe em opiniões Compras, MRP2 e gerenciamento de qualidade. Ao fazer as regras e o programa de carregamento, o mesmo campo pode estar em diferentes visualizações. Para resolver isso, proceda da seguinte forma:
Veja com todos os domínios implicados que são o líder do campo e decida em qual exibição o campo deve ser incluído.
Tomando o exemplo do campo # 8220; Tempo de processamento de recebimento de mercadorias em dias (MARC-WEBAZ) & rdquo ;, pode ser decidido entre os domínios para colocá-lo na visão de Compras (e em nenhum outro lugar).
Conversão mestre de material:
Design de processo de alto nível.
Estas são todas as principais visualizações envolvidas no Material Master Object:
Dados básicos alternativos UOM Inspeção Classificação de texto Organização de vendas Vendas Geral Compra de plantas Comércio externo Importar & amp; Exportar dados mestre APO MRP1 & amp; 2 Contabilidade de gerenciamento de qualidade.
Normalmente, a especificação da função Os proprietários farão o método de gravação para capturar todos os campos nas visualizações acima e preparar a lógica de mapeamento.
O projeto mais complexo envolve a fusão e mesclagem da planta. (Referir documento de processo de alto nível)
Um grupo de membros do grupo de segmento de clientes de tipo é uma coleção de usuários, conforme definido pelo Vendedor ou comerciante, que compartilham um interesse comum.
Por exemplo: Uma empresa de mineração tem CSG & # 8217; s como Cerro Matoso (CMSA), Met Coal (MTCO), Base Metals (BASE) etc.,
Com base nos dados CSG & # 8217; s, os dados precisam ser divididos antes de serem carregados através do LSMW para avaliação.
A lógica de divisão pode ser feita por Loop Component em Business Objects Data Services.
Obtenha os CSG e # 8217; s distintos em um fluxo de dados. Atribua uma variável para o número de sequência para o valor máximo e o loop a partir da inicial.
Outros Negócios Conversão de objetos:
Para os outros BO, porque são mais simples do que o Material Master e envolvem menos pessoas, começaremos diretamente com o documento de regras de conversão. É neste documento que ambos vamos decidir quais os campos que precisamos e, em uma segunda etapa, começar a trabalhar nas regras.
Aqui estão algumas amostras de regras de conversão BO.
Exemplo de regras de conversão da lista técnica.
Abra a amostra de regras de conversão de contas a receber.
Exemplo de regras de conversão do Fornecedor Master.
Observe que o termo SAP & # 8220; depósito de segurança & rdquo; igual & # 8220; Retenção & rdquo; no PRMS.
Tipo de transação.
Campo TYPE no PRMS:
Qualquer outro tipo é um erro.
Validação para aplicar tanto na extração quanto na carga.
Parcial PMT & hellip; & hellip; & hellip ;. deve ser negativo no PRMS, se não ERROR.
Credit Memo & hellip; & hellip; & hellip; deve ser negativo no PRMS, se não ERROR.
Debit Memo & hellip; & hellip; & hellip;. Devem ser positivos no PRMS, se não ERROR.
Qualquer outro tipo é um ERRO.
LSM Load parameters.
KTOPL & # 8211; Gráfico de conta: CA00.
BUKRS & # 8211; Código da empresa: 0070.
GSBER & # 8211; Área de negócios: 0040.
BUDAT & # 8211; Data de lançamento: & # 8220; 05-31-02 & rdquo; ou último dia do último período fechado.
OFFSET & # 8211; Conta (2): REPRODUÍDO.
SKPERR & # 8211; Skip err: X.
W orkbench M igration de L e Igualdade (LSMW):
O LSMW é usado para migrar dados de um sistema herdado para o sistema SAP, ou de um sistema SAP para outro.
Além das entradas e gravações padrão de lote / direto, BAPI e IDocs estão disponíveis como métodos de importação adicionais para processar os dados legados.
O LSMW compreende as seguintes etapas principais:
Leia dados (dados legados em tabelas de planilhas e / ou arquivos seqüenciais). Converta dados (da fonte para o formato de destino). Importar dados (para o banco de dados usado pelo aplicativo R / 3.
Mas, antes destas etapas, você precisa executar as seguintes etapas:
Definir estrutura de origem: estrutura de dados no arquivo de origem. Definir estrutura de destino: estrutura do SAP que recebe dados. Mapeamento de campo: Mapeamento entre a estrutura de origem e destino com as conversões, se houver. Especificar arquivo: local do arquivo de origem.
Métodos utilizados para migração de dados, como BDC, LSMW e Call Transaction.
Todos os 3 métodos são usados para migrar dados. A seleção desses métodos depende do cenário, a quantidade de dados precisa ser transferida. LSMW é uma ferramenta pronta fornecida pela SAP e você deve seguir algumas 17 etapas para migrar dados mestre. Enquanto no método de sessão BDCs é a melhor escolha devido a algumas vantagens sobre a transação de chamada. Mas a transação de chamadas também é muito útil para atualizar imediatamente uma pequena quantidade de dados. (O desenvolvedor de transações de chamadas deve lidar com erros).
SO Bottom line é fazer a escolha desses métodos com base em requisitos de tempo real.
Esses métodos são escolhidos completamente com base na situação em que você está. O método de entrada direta não está disponível para todos os outros cenários, eles são os mais simples. No método de entrada em lote, você precisa fazer a gravação para a transação em questão. Da mesma forma, o IDoc e a BAPI estão lá, e o uso destes deve ser decidido com base no requisito.
Tente passar por algum material sobre esses quatro métodos e implemente-os. Você terá uma idéia justa sobre quando usar o qual.
BDC & # 8211; É a comunicação de dados em lote. É usado para conversão de dados do sistema antigo para o sistema SAP. Somente pessoas técnicas podem fazê-lo. O Tcode é SHDB.
LSMW & # 8211; É o banco de trabalho de migração do sistema legado. Também é usado para conversão de dados do sistema herdado para o sistema SAP. Mas é um papel de consultor funcional.
Existem 14 passos no LSMW. Assim que você completar um passo, automaticamente ele irá para o próximo passo.
Em geral, você pode usar LSMW. Mas se você deseja transferir mais de 40.000 dados, então não é possível no LSMW. Naquele momento você pode ajudar com o BDC.
Migração de dados LSMW para cliente de cliente VA01 / XD01.
8 Comentários.
Você deve estar conectado para comentar ou responder a uma postagem.
A SAP oferece conteúdo gratuito para ajudar a migrar dados em SAP (ERP, CRM, etc.). Veja websmp103.sap-ag. de/rds-dm2erpcrm.
Esta é realmente uma boa explicação para o processo de migração de dados.
Artigo muito informativo (provavelmente o melhor). Continue postando.
Um documento bom, estruturado e bem escrito.
Grande literatura.
Obrigado por compartilhar o conhecimento.
bom artigo Johnpaul!
Wow Johnpaul este é um ótimo artigo! É muito informativo e passa por um monte de requisitos para uma migração bem-sucedida. No Method360, percebemos que muitas pessoas não gastam a quantidade necessária de planejamento de tempo para as migrações e acabam tendo que voltar atrás e gastar muito tempo re-fazer coisas que deveriam ter sido feitas muito mais cedo, especialmente em as etapas de purga e limpeza de dados. Os clientes pensam que, uma vez que são transferidos para o sistema mais novo, tudo será consertado, mas acabará com um sistema lento com muitos erros. Passar o tempo para rever seus dados históricos e mestre que podem ter mudado ou não é mais necessário pode realmente acelerar seus sistemas. Para ajudar os clientes a entender tudo o que precisam para ser bem-sucedidos, criamos uma oficina gratuita. Sinta-se à vontade para dar uma olhada!
Cadastro.
Para se beneficiar plenamente do que a Comunidade SAP tem para oferecer, inscreva-se em:
A equipe da comunidade SAP.
Создал (а) Preeti Yadav, редактировал (а) Craig Cmehilмая 06, 2008.
1. Introdução.
Este documento fornece uma visão geral dos processos e metodologias de conversão de dados que podem ser usados na indústria de fabricação, que estão prontos para passar de um sistema ERP para outro sistema ERP (SAP R / 3).
O objetivo deste documento é descrever descrições detalhadas dos processos de conversão.
A conversão de dados é a conversão de uma forma de dados de computador para outro formulário com a finalidade de interoperabilidade de aplicativos ou de capacidade de usar recursos de novo sistema que requer envolvimento ativo de usuários empresariais para torná-lo correto. Geralmente, é recomendado quando uma organização se move completamente / parcialmente do sistema herdado para o novo sistema e também deseja corrigir os dados do seu antigo sistema.
2. Visão geral.
Em qualquer implementação para um novo sistema do sistema existente, a conversão de dados é essencial e crítica.
Seguindo entidades / objetos comerciais que abrangem todos os aspectos do SAP (PTP, OTC e PME) no âmbito do processo de conversão.
Item Mestre Fornecedor Mestre Cliente Mestre Números do programa.
Aberto Acordo de agendamento / Ordem de compra Pricing Abrir agendamento Acordo / Ordens de compra Abrir o preço do pedido de venda Abrir Pedidos de vendas Dados de custo padrão Saldos de inventário Bancário e banco de fornecedores Transações entre empresas Deliberações de saída Abrir AP Abrir AR.
Finanças e Controle de Dados:
CostCenter Asset Master e Transações de ativos Saldos de conta do Razão Pedidos Internos.
3. Processo de conversão.
Com base nas complexidades e múltiplas partes interessadas definidas na seção Visão geral, o processo de conversão de dados foi categorizado em 4 etapas, nomeadamente.
Extração de pré-limpeza Limpeza, enriquecimento e transformação Validação pré e pós-carregamento, Suporte de carregamento e pós-carga Assinatura.
3.1. Pré-limpeza.
Como o nome sugere, a pré-limpeza é o processo que começa antes da limpeza e foi uma das atividades críticas e importantes. Ele lida com as atividades realizadas no sistema existente / existente antes mesmo de tentar extrair dados para o novo sistema.
O usuário comercial (como o controlador de fábrica, o gerente de planta, a comunidade de compras, a comunidade de vendas, o custeio central e as finanças, a gestão da cadeia de suprimentos, etc.), juntamente com a liderança de TI (juntamente com 1 ou 2 desenvolvedores do sistema ERP existente) costumava impulsionar esse processo.
A intenção deste processo é levar o proprietário dos dados de diferentes unidades a uma plataforma comum e fazê-los concordar com a quantidade e qualidade dos dados a serem convertidos.
Durante todo o processo, as partes interessadas envolvem brain storming, discussão sobre o que deve ser feito na SAP ou o que não deveria. Nas tabelas do banco de dados pertencentes a esses objetos de negócios, isto é, Item, PO, SO etc., um campo chamado "GOSAP" foi criado. Uma vez que a decisão foi tomada sobre um PO / SO e suas partes relacionadas, esse campo costumava ser preenchido com "GOSAP" ou "NOSAP". Itens de linha com o valor de "GOSAP & quot; só procuraram processamento adicional.
Ele é executado para cada planta em uma determinada implantação para tirar um instantâneo dos dados em qualquer momento. Esta costumava ser uma atividade semanal que costumava mostrar os itens de ação para participantes interessados ou um grupo de participantes.
O relatório inclui o seguinte:
Objeto de negócios e seus atributos críticos relacionados,
Registros - Contagem de desconectas.
Porcentagem - Que parte dos dados estavam em desconectas, em comparação com a contagem total de registros para um determinado objeto de negócios.
A maioria das questões relacionadas ao negócio foi respondida com base neste relatório.
Identifique o número de peças que precisam de peças convertidas que são obsoletas, mas que possuem partes PO / SO ativas que têm custo padrão como 0 PO ativo / SOs, mas não registros de condições correspondentes, ou seja, preços Fornecedores ativos, mas sem transações (ou seja, PO) associadas a eles são clientes ativos, mas nenhuma transação (ou seja, SO) associada a eles POss estão ativos, mas os vendedores correspondentes não são mais necessários. SOs estão ativos, mas os clientes correspondentes não são mais necessários. Discrepâncias entre a venda de moeda de preços e a moeda de preço de compra.
É assim que se parece um relatório de pré-limpeza para intercompany para tratar as transações entre empresas separadamente.
A maioria das questões relacionadas entre as empresas foram respondidas com base neste relatório.
As mesmas partes são descritas de forma diferente em diferentes plantas, ou seja, o mesmo número de peça com detalhes diferentes ou a mesma descrição da peça, mas o número de peça diferente, ou seja, a combinação de descrição As discrepâncias dos preços para as mesmas peças entre 2 plantas, como a planta de venda, estão citando um preço de venda quando as unidades de compra mostrarem diferentes preço, isto é, falta de preços de preços As discrepâncias das peças entre as plantas, como uma planta, dizem que estão vendendo, mas outras estão dizendo que elas não estão recebendo ou vice-versa, ou seja, o número de linhas de PO em uma planta não está combinando com o número de SO de quem ele está comprando Preços Desajuste monetário entre as unidades de transação Unidade de medida (UoM) incompatibilidade Correspondência difícil - Quando o PO, o número da linha e as peças correspondem à planta de compras combinadas com SO, o número da linha e as peças da planta de venda Soft Match - Quando apenas o PO e as peças correspondem à compra planta com SO e número de linha da venda de plantas.
All the above mentioned analysis either for 3 rd party or intercompany were discussed in detail with the concerned data owner to arrive at a common platform so that putting junk/garbage into new system could be avoided.
The decisions based on the data owner analysis were as follows.
Convert PO/SO`s only for identified active parts Convert Vendor/Customer based on these active PO/SO`s thus making master data dependent on the transaction data Maintain standard costs for the active items Maintain condition records i. e. Pricing for every PO/SO`s except for future or release orders to customer Resolve selling and buying currency issues and adjusting the prices accordingly For intercompany, Resolve price, parts, currency, UoM discrepancies by doing workshop with both plant controller and central costing and finance team.
3.2. Extract.
After pre-cleansing was done or reaching at the final stages, Data pertaining to each business objects used to be extracted from the legacy system. The extract program was designed with the help of data and process owner considering the correct mapping of fields from legacy system to SAP system. It was developed by the existing system developer in the existing system language and was stored in the central repository called Livelink. For any deployment, the program used to be exported to respective plant database and was executed. The extracts for all the business objects used to be taken at the same time to avoid any discrepancies among the master data and transaction data. Atleast for every legacy field, a new SAP field had been added in the program so that while cleansing/enrichment, data owner compares the values without going into the existing system.
Data used to be extracted in its entirety from the old system which means no business logic in the extraction program/scripts thus reducing one level of complexities. During the pre-cleansing all the data which needed to be converted in the target system was flagged with "GOSAP/NOSAP" status. The cleansing team used to filter the relevant data based on this flag. Data were always extracted and put into flat files for further processing.
3.3. Cleansing, Enrichment and Transform.
As the title suggests, it describes 3 steps in the conversion process.
- Cleansing - Modify/make corrections in the existing data.
- Enrichment - Provide Information which are not present in the existing system but are needed by SAP system.
- Transform - Transform the cleansed/enriched data into load format using a tool called "Trillium"
Though the definition seems quite simple, it was as exhaustive as pre-cleansing cleansing. During this process of conversion completeness, correctness and accuracy of the data is one of the critical tasks which were done during this process.
After Extraction of the data for all the business objects, the data used to be formatted based on pre-defined formatting rules using Trillium and sent to business users/data owners to validate the existing information and provide the additional information (called enrichment) needed by SAP e. g. Vendors have name, address, city, zip code, Phone etc were already present in the existing system which the purchasing community were asked to validate for correctness but they were also asked to fill the information like Sales contact, Commodity that these vendors are supplying, Inco terms, Whether the vendor is minority vendor etc etc which formed the enrichment part. There were data owners for each process areas like PTP, PME and OTC and one had to follow up constantly to get the correct and accurate data from these owners.
Once the cleansed and enriched were sent back, it used to be run again in Trillium to prepare the LSMW input flat file.
For data transformation i. e. cleansing or static enrichment, Trillium was used. A lot of customization has been done in Trillium to get the data file in the format as needed by LSMW tool.
Trillium was preferred as compared to Microsoft access as the formatting tool because of the following reason:
De-duplication and identifying relationships are inbuilt features in Trillium so no manual effort for de-duplication Data Cleansing and Standardization are inbuilt again features in Trillium. So customization to certain extent would give maximum output. Handle multi plants and huge volume of data efficiently and comfortably.
During this process of conversion, data were loaded into SAP system using the upload tool from SAP called LSMW. The LSMW was customized to validate business needs especially for mandatory value attributes, dependencies, sequences and format. Hence it used to serve as the last validation juncture to identify the correctness of the data.
Every business objects had their own customized program.
3.5. Validation after Load.
Reports were developed and run in the SAP system and compare the results against what were extracted/cleansed/enriched and what got loaded to validate the correctness of the data and thus create the credibility between the data owner with the new system.
3.6. Signoff.
This exercise is done before and after the production load so that issues could be resolved before the data gets loaded in production and before the plants go live in SAP.
1 комментарий.
I notice that you do not mention open production orders in your transactional data. What is your suggestion here? My client cannot close all open production order prior to cutover so we need to find an adequate conversion method. We already have a strain on development resources which threatens to push the date, so I want to avoid any more custom code. Are you aware of any standard LSMW objects - direct input, batch input, IDoc or BAPI - that would help here?
Como planejar uma conversão de dados bem sucedida em seu movimento para a Fusion.
Jon Wakefield é consultor sênior da Oracle Line of Business na Velocity e tem mais de 16 anos de experiência funcional e técnica em produtos Oracle, incluindo PeopleSoft, Fusion e Taleo. Como parte da equipe de serviços profissionais da Velocity & rsquo; Jon é responsável pelo novo desenvolvimento e implementação de soluções Oracle. Ele pode ser alcançado em jonathan. wakefieldvelocity. cc.
Muitas organizações estão se movendo para os serviços da nuvem Oracle Fusion, aproveitando os níveis aprimorados de suporte e redução geral no custo de propriedade que o produto oferece. Se a sua organização se prepara para implementar o Fusion (clique aqui para obter algumas dicas úteis sobre como tomar essa decisão), há, é claro, uma série de fatores a serem considerados e planejados de acordo. Nesta publicação, vou me concentrar em um dos maiores, cujo impacto muitas vezes pode ser subestimado: conversão de dados Oracle.
Como o Fusion é um produto SaaS, você não terá acesso para atualizar nenhuma das tabelas e, em vez disso, deve aproveitar as ferramentas de conversão de dados que a Oracle fornece para preencher o Fusion com os dados da sua organização. A principal ferramenta com a qual você trabalhará é o FBL (File-Based Loader), e é crítico para levar o tempo inicial para entender como a ferramenta funciona e quais objetos de negócios ele suporta (clique aqui para o guia do usuário da Oracle e rsquo; lista de objetos).
Carregando dados no Oracle Fusion.
A chave para carregar com sucesso seus dados no Fusion é sobre como você extrai esses dados do seu antigo sistema. O FBL requer que você crie uma série de arquivos delimitados por tubos (.dat ou. csv) contendo todos os dados que deseja carregar no Fusion, formatados de acordo com as especificações do Oracle & rsquo; clique aqui para uma planilha de cada campo suportado e seu formato) . O FBL então importa esses arquivos e preenche as tabelas Fusion de acordo com os valores que você incluiu para cada campo. Você deve projetar um processo para preencher com atenção os arquivos que você considera necessários, certificando-se de que cada valor de campo esteja formatado e posicionado corretamente. Se você fizer isso, reduzirá seus possíveis erros de carga e removerá muitos riscos e estresse do processo de conversão de dados.
Você pode usar qualquer número de opções para conseguir isso, mas para você começar, I & rsquo; fornecerá três abordagens diretas que podem funcionar bem para você. Eles são orientados para o PeopleSoft, pois essa era minha principal experiência antes de aprender o Fusion, mas os conceitos básicos que conduzem cada um também são aplicáveis a outros sistemas de ERP.
3 Opções de Estratégia de Conversão de Dados para o Oracle Fusion Data Loading.
Se você não pensa, a Query pode acomodar o esforço de conversão da sua organização e você não quer criar SQRs, uma boa alternativa poderia ser & hellip;
Obrigado por se inscrever.
&cópia de; 2017 Velocity Technology Solutions, Inc. Todos os direitos reservados.
Este documento fornece um procedimento para ajudá-lo a organizar e executar a transferência de dados do sistema herdado.
Ele descreve uma metodologia para migração de dados que usei com sucesso em diferentes implementações. Baseia-se nas minhas experiências anteriores. Não há garantia sobre o conteúdo ou sobre os resultados. Este guia oferece sugestões. Cabe a você seguir as dicas e criar sua própria metodologia.
Terminologia comum e abreviaturas em projetos de migração:
Nota: Os termos SAP e R / 3 são ambos utilizados de forma intercambiável para se referir ao sistema SAP R / 3.
Big Five: quando se refere aos Big Five, significa Mestre de Materiais, Mestre de Clientes, Mestre de Fornecedores, Lista de Materiais (BOM) e Roteiros.
Objetos comerciais: para ajudar no processo de análise e transferência, os dados não são tratados como tabelas ou conteúdo de campo, mas sim como objetos em termos de negócios operacionais. Estes são chamados Business Objects.
Business Object DC responsável: responsável pelo processo de conversão (fonte de dados legados e integridade, mapeamento, regras de conversão, etc.) e pelo respeito da programação planejada para o objeto comercial.
Proprietário do objeto de negócios: aquele que possui a informação no negócio do cotidiano. Esta é a pessoa que irá fazer as escolhas estratégicas sobre requisitos funcionais para o objeto de negócios e que fará a validação final dos dados convertidos. Pode ser identificado ao encontrar a pessoa hierárquica mais alta que será diretamente e principalmente afetada se o objeto de negócios não funcionar & rdquo;
Conversão de dados e amp; Migração de dados: o processo de conversão de dados. & # 8220; Conversão de dados & rdquo; e & # 8220; Data Migration & rdquo; Os termos são usados indistintamente no documento.
DC: Abreviação do processo de conversão de dados.
Domínio: domínio funcional dentro do projeto, como Finanças, Vendas, Produção, etc.
Arquivo plano: um formato de arquivo usado para importar dados para o SAP. O arquivo plano é um arquivo de texto simples com um separador de separadores entre campos. Pode ser facilmente gerado a partir do Excel ou Acesso.
Arquivo intermediário: um Excel, acesso ou outro tipo de arquivo, que é manipulado manualmente em um processo entre a extração LS e a geração de arquivos planos.
LSMW: Legacy System Migration Workbench. É uma ferramenta SAP para conversão que permite o carregamento de dados usando arquivos planos extraídos do Sistema Legado.
Tabela de referência cruzada ou tabela X-Ref: Uma tabela que mostra a relação entre campos quando um valor está relacionado a um campo pai. Por exemplo, a & # 8220; Organização de vendas & # 8221; será configurado de acordo com o tipo de material.
WBS: estrutura de repartição do trabalho.
Implementar o SAP é um desafio importante, tanto em termos de recursos (pessoas, dinheiro, tempo) como em processos comerciais. Muito está em jogo e, para a maioria de vocês, o fracasso não é uma opção que você pode pagar. Para colocar todas as probabilidades do seu lado, você precisa de uma boa metodologia. Um que irá fornecer-lhe um planejamento realista, uma organização sólida, uma maneira de gerenciar o processo e ferramentas de controle para detectar e corrigir o deslizamento antes que ele se torne um problema.
Antes mesmo de começar a trabalhar em especificações, você deve primeiro se organizar. Obter uma boa estrutura de planejamento e organização leva cerca de duas semanas para o primeiro rascunho, o que o deixará com algumas questões sobre a organização do projeto. Obter um planejamento completo e final levará pelo menos mais uma semana. Qualquer problema não resolvido sobre estes irá assombrá-lo durante todo o projeto, então termine isso completamente antes de indicar qualquer outro passo.
A conversão de dados requer recursos funcionais e técnicos da maioria dos departamentos. Estes mesmos recursos provavelmente estarão envolvidos em outra parte do projeto. Por esta razão, o risco de uma tarefa conflitante é alto e pode levar rapidamente a um gargalo onde os povos-chave estão sobrecarregados. Por esse motivo, você deve considerar a conversão de dados como um projeto dentro do projeto. Isso se traduz na preparação de um plano de conversão completo que o ajudará a passar pelo processo e permitirá prever e resolver o uso de recursos em conflito antes do gargalo que já ocorreu.
Os principais passos da conversão de dados são:
Organização da conversão de dados (Gerente de projeto e coordenador de conversão de dados)
Plano de conversão de dados O WBS com estimativa de carga de trabalho O planejamento do calendário com o carregamento de recursos.
Iniciando com a conversão de dados do Business Objects (O recurso responsável pelo Business Object DC)
Data Purging and Cleansing Mapeamento e regras de conversão Extrair e carregar programas de regras Adaptação de dados e regras (regras de ajuste e programas após o teste) Teste de unidade de carga (teste unitário e pequeno volume de dados manuais) Extração e carga Testes de tamanho completo (dados teste e validação / grande volume com dados extraídos de verdade) carregamento de dados completos no sistema de aceitação carregamento completo de dados no sistema de produção prévia Validação de dados convertidos e Key User + Business Objects Inscrição do proprietário Conversão completa em SYSTEME DE PRODUÇÃO e sinalização final.
Plano de conversão de dados.
Objetos empresariais.
Um objeto de negócios é uma categoria geral para dados que define algo como mestre de material, mestre de fornecedores, ações, pedidos, requisições de compra ou unidades organizacionais. O primeiro passo é identificar quais objetos comerciais (Objetos) são necessários na sua implementação SAP.
Existem três tipos de dados envolvidos em um sistema SAP: dados mestre, dados transacionais e dados históricos.
Dados mestre. Os dados mestre de aplicativos tendem a ser mais estáticos, uma vez definidos. A maioria dos dados mestre pode ser conduzida pelas aplicações legadas. Os exemplos incluem fornecedores, clientes, gráficos de contas, ativos, contas de materiais, mestres de materiais, registros de informações, e assim por diante. Dados Transacionais. Os dados transacionais são dados de transações atuais e pendentes que precisam ser capturados pelo sistema antigo e definidos para os aplicativos SAP R / 3 para a conclusão do processo comercial. Exemplos incluem documentos contábeis, ordens de compra abertas, ordens de vendas abertas, pedidos atrasados e assim por diante. Data histórica. Os dados históricos precisam ser transferidos do sistema herdado para o sistema SAP R / 3 para fins de referência. Os exemplos incluem pedidos de compra fechados, ordens de vendas fechadas, informações gerais do resumo, e assim por diante.
Informações para completar o plano de conversão.
O que objetos de negócios serão convertidos do sistema herdado para o SAP. Onde onde estão os dados, quais sistemas Legacy estão envolvidos para a extração. Quanto estimar o número de registros a serem carregados no SAP. Como há dois aspectos a serem considerados: a forma como os dados são extraídos do Sistema Legado Extraído automaticamente do sistema Legacy sem intervenção manual. Folha de cálculo preenchida manualmente Combinação de uma extração automática do sistema Legacy + Entrada manual em uma planilha A forma como os dados são injetados no SAP: Transferência automática de dados a partir de um arquivo plano para o SAP Inserção manual de dados com transações online para SAP Combinação de ambos.
O método de transferência de dados que você escolherá determinará os tipos de recursos que você precisa. Por exemplo, você pode precisar de funcionários temporários para a entrada manual de dados e programadores para escrever seus próprios programas de extração. Você precisa saber quais são os dados no seu sistema legado e quais aplicativos SAP correspondem aos objetos de negócios que serão transferidos. Uma pessoa não precisa saber tudo isso, mas as pessoas que conhecem essa informação devem trabalhar em estreita colaboração.
Quem é envolvido em cada Objeto de Negócios: Usuário-chave (responsável funcional da conversão BO: Regras, correções de dados manuais, teste, validações) Consultor Responsável pela limpeza e purga de dados no Sistema Legado Responsável pela extração Responsável pelo carregamento de dados no SAP Business Gerenciador de objetos (proprietário hierárquico responsável pelo uso do dia-a-dia e integridade da informação e aquele que será assinado para aceitação de dados)
Main Business Objects seqüência de conversão:
CONVERSANDO UM OBJETO DE NEGÓCIO:
Data Purging and Cleansing.
A purga e limpeza do sistema Legacy irá poupar muito tempo e esforço nas seguintes etapas da conversão. Comece assim o mais rápido possível e faça o máximo possível. Isso pode ser feito sem conhecimento específico do SAP.
Antes de transferir dados do seu sistema antigo, exclua todos os dados antigos e obsoletos. Por exemplo, você pode excluir todos os clientes únicos ou aqueles para os quais não houve transação nos últimos dois anos, também excluir materiais não utilizados.
Este processo corrige inconsistências de dados e garante a integridade dos dados existentes durante o processo de migração. Por exemplo, muitas vezes há muitas inconsistências nos campos de endereços do cliente e do fornecedor. Você encontrará rapidamente que o SAP não permitirá que você carregue nenhum campo de endereço, a menos que você os limpe.
Regras de mapeamento e conversão.
A documentação de cada objeto comercial conterá as regras (ou especificações) de conversão de dados, que incluem:
* Fontes legadas e procedimentos de extração.
De qual sistema (s) Legacy estamos extraindo os dados e como. Documente aqui as etapas específicas que precisam ser tomadas.
Quais são as etapas de limpeza a serem tomadas e os filtros de extração a serem usados.
Diretrizes para aplicar ou regras que são usadas por muitos campos (evitando assim reescrevê-lo e tornar a atualização mais fácil, pois é apenas em um só lugar).
Quais campos SAP usar e como podemos obter o valor final para cada campo SAP.
As regras gerais são aquelas que não se destinam diretamente a um valor de campo. Por exemplo, a forma como diferenciamos os tipos de material no Sistema Legado é uma regra. As regras de campo são aquelas que dão um valor para um campo específico.
Isso é crucial. Ao discutir ou escrever notas, SEMPRE se referir a um campo no formato TABLE-FIELD. Você perceberá rapidamente que, à medida que o projeto vai, diferentes pessoas começarão a usar nomes diferentes para o mesmo campo. Além disso, eles podem começar a usar o mesmo nome para diferentes campos.
Além disso, alguns campos existem em diferentes visualizações nos dados mestre SAP. Algum tempo é o mesmo campo que é mostrado em dois lugares, enquanto outras vezes são realmente dois campos diferentes. A melhor maneira de saber que caso se aplica é ter a informação TABLE + FIELD.
Em Material Master, o campo & # 171; Verificação de disponibilidade & raquo; existe no & # 8220; MRP2 & # 8221; e o & # 8220; Sales Gen & # 8221; pontos de vista. Se você olhar para a TABELA-CAMPO de cada visualização, você obtém:
Sales Gen: MARC-MTVFP.
Em ambos os casos, o nome do TABLE-FIELD é o mesmo, então é o mesmo campo.
Em Customer Master, o campo & # 8221; Termos de pagamento e # 8217; existe em & # 8220; Transações de pagamento & # 8221; e & # 8220; Faturamento & # 8221; pontos de vista. Se você olhar para a TABELA-CAMPO de cada visualização, você obtém:
Transações de pagamento: KNVV-ZTERM.
Exibições de faturamento: KNB1- ZTERM.
Não é o mesmo campo. Na visualização de pagamento, o campo está vinculado ao Código da Empresa, enquanto que para a visualização de Faturamento está vinculado à Organização de Vendas (você encontra isso observando as teclas de tabelas). Portanto, esses dois campos podem ter valores diferentes.
Metodologia Técnica.
Um caso especial para Material Master.
O Mestre de Materiais envolve todos os domínios e pode exigir em qualquer lugar de 20 campos para algumas centenas dependendo da complexidade de sua implementação. Alguns campos serão usados por diferentes domínios, enquanto outros serão usados por um único domínio, mas seu valor terá um impacto na funcionalidade usada por outro domínio.
Este é o Objeto de Negócios mais complexo para documentar e, ao mesmo tempo, é aquele com o qual você deve começar com o processo de conversão.
1º passo: seleção dos campos por cada domínio.
Obtenha cada domínio com seus consultores para passar pelo arquivo de mapeamento e veja os campos para cada tipo de material. O objetivo aqui é ver todos os campos importantes e fazer perguntas para compreendê-los. Isso é feito separadamente por cada domínio e documentado em diferentes arquivos de mapeamento. Nesses pontos, não nos interessa a respeito de onde os valores virão e como os obteremos. APENAS CONSIGUE O MAPEAMENTO E façam a compreensão do que é o mestre do material. Cada vez que um domínio seleciona um campo para um tipo de material específico, eles devem inserir seu tipo de domínio na lista. Aqui estão alguns exemplos (teóricos) de mapeamento de MM, PP e SD.
No Material Master, alguns campos podem ser inseridos / modificados em diferentes visualizações. Por exemplo, o campo & # 8220; Tempo de processamento de recebimento de mercadorias em dias (MARC-WEBAZ) & rdquo; existe em opiniões Compras, MRP2 e gerenciamento de qualidade. Ao fazer as regras e o programa de carregamento, o mesmo campo pode estar em diferentes visualizações. Para resolver isso, proceda da seguinte forma:
Veja com todos os domínios implicados que são o líder do campo e decida em qual exibição o campo deve ser incluído.
Tomando o exemplo do campo # 8220; Tempo de processamento de recebimento de mercadorias em dias (MARC-WEBAZ) & rdquo ;, pode ser decidido entre os domínios para colocá-lo na visão de Compras (e em nenhum outro lugar).
Conversão mestre de material:
Design de processo de alto nível.
Estas são todas as principais visualizações envolvidas no Material Master Object:
Dados básicos alternativos UOM Inspeção Classificação de texto Organização de vendas Vendas Geral Compra de plantas Comércio externo Importar & amp; Exportar dados mestre APO MRP1 & amp; 2 Contabilidade de gerenciamento de qualidade.
Normalmente, a especificação da função Os proprietários farão o método de gravação para capturar todos os campos nas visualizações acima e preparar a lógica de mapeamento.
O projeto mais complexo envolve a fusão e mesclagem da planta. (Referir documento de processo de alto nível)
Um grupo de membros do grupo de segmento de clientes de tipo é uma coleção de usuários, conforme definido pelo Vendedor ou comerciante, que compartilham um interesse comum.
Por exemplo: Uma empresa de mineração tem CSG & # 8217; s como Cerro Matoso (CMSA), Met Coal (MTCO), Base Metals (BASE) etc.,
Com base nos dados CSG & # 8217; s, os dados precisam ser divididos antes de serem carregados através do LSMW para avaliação.
A lógica de divisão pode ser feita por Loop Component em Business Objects Data Services.
Obtenha os CSG e # 8217; s distintos em um fluxo de dados. Atribua uma variável para o número de sequência para o valor máximo e o loop a partir da inicial.
Outros Negócios Conversão de objetos:
Para os outros BO, porque são mais simples do que o Material Master e envolvem menos pessoas, começaremos diretamente com o documento de regras de conversão. É neste documento que ambos vamos decidir quais os campos que precisamos e, em uma segunda etapa, começar a trabalhar nas regras.
Aqui estão algumas amostras de regras de conversão BO.
Exemplo de regras de conversão da lista técnica.
Abra a amostra de regras de conversão de contas a receber.
Exemplo de regras de conversão do Fornecedor Master.
Observe que o termo SAP & # 8220; depósito de segurança & rdquo; igual & # 8220; Retenção & rdquo; no PRMS.
Tipo de transação.
Campo TYPE no PRMS:
Qualquer outro tipo é um erro.
Validação para aplicar tanto na extração quanto na carga.
Parcial PMT & hellip; & hellip; & hellip ;. deve ser negativo no PRMS, se não ERROR.
Credit Memo & hellip; & hellip; & hellip; deve ser negativo no PRMS, se não ERROR.
Debit Memo & hellip; & hellip; & hellip;. Devem ser positivos no PRMS, se não ERROR.
Qualquer outro tipo é um ERRO.
LSM Load parameters.
KTOPL & # 8211; Gráfico de conta: CA00.
BUKRS & # 8211; Código da empresa: 0070.
GSBER & # 8211; Área de negócios: 0040.
BUDAT & # 8211; Data de lançamento: & # 8220; 05-31-02 & rdquo; ou último dia do último período fechado.
OFFSET & # 8211; Conta (2): REPRODUÍDO.
SKPERR & # 8211; Skip err: X.
W orkbench M igration de L e Igualdade (LSMW):
O LSMW é usado para migrar dados de um sistema herdado para o sistema SAP, ou de um sistema SAP para outro.
Além das entradas e gravações padrão de lote / direto, BAPI e IDocs estão disponíveis como métodos de importação adicionais para processar os dados legados.
O LSMW compreende as seguintes etapas principais:
Leia dados (dados legados em tabelas de planilhas e / ou arquivos seqüenciais). Converta dados (da fonte para o formato de destino). Importar dados (para o banco de dados usado pelo aplicativo R / 3.
Mas, antes destas etapas, você precisa executar as seguintes etapas:
Definir estrutura de origem: estrutura de dados no arquivo de origem. Definir estrutura de destino: estrutura do SAP que recebe dados. Mapeamento de campo: Mapeamento entre a estrutura de origem e destino com as conversões, se houver. Especificar arquivo: local do arquivo de origem.
Métodos utilizados para migração de dados, como BDC, LSMW e Call Transaction.
Todos os 3 métodos são usados para migrar dados. A seleção desses métodos depende do cenário, a quantidade de dados precisa ser transferida. LSMW é uma ferramenta pronta fornecida pela SAP e você deve seguir algumas 17 etapas para migrar dados mestre. Enquanto no método de sessão BDCs é a melhor escolha devido a algumas vantagens sobre a transação de chamada. Mas a transação de chamadas também é muito útil para atualizar imediatamente uma pequena quantidade de dados. (O desenvolvedor de transações de chamadas deve lidar com erros).
SO Bottom line é fazer a escolha desses métodos com base em requisitos de tempo real.
Esses métodos são escolhidos completamente com base na situação em que você está. O método de entrada direta não está disponível para todos os outros cenários, eles são os mais simples. No método de entrada em lote, você precisa fazer a gravação para a transação em questão. Da mesma forma, o IDoc e a BAPI estão lá, e o uso destes deve ser decidido com base no requisito.
Tente passar por algum material sobre esses quatro métodos e implemente-os. Você terá uma idéia justa sobre quando usar o qual.
BDC & # 8211; É a comunicação de dados em lote. É usado para conversão de dados do sistema antigo para o sistema SAP. Somente pessoas técnicas podem fazê-lo. O Tcode é SHDB.
LSMW & # 8211; É o banco de trabalho de migração do sistema legado. Também é usado para conversão de dados do sistema herdado para o sistema SAP. Mas é um papel de consultor funcional.
Existem 14 passos no LSMW. Assim que você completar um passo, automaticamente ele irá para o próximo passo.
Em geral, você pode usar LSMW. Mas se você deseja transferir mais de 40.000 dados, então não é possível no LSMW. Naquele momento você pode ajudar com o BDC.
Migração de dados LSMW para cliente de cliente VA01 / XD01.
8 Comentários.
Você deve estar conectado para comentar ou responder a uma postagem.
A SAP oferece conteúdo gratuito para ajudar a migrar dados em SAP (ERP, CRM, etc.). Veja websmp103.sap-ag. de/rds-dm2erpcrm.
Esta é realmente uma boa explicação para o processo de migração de dados.
Artigo muito informativo (provavelmente o melhor). Continue postando.
Um documento bom, estruturado e bem escrito.
Grande literatura.
Obrigado por compartilhar o conhecimento.
bom artigo Johnpaul!
Wow Johnpaul este é um ótimo artigo! É muito informativo e passa por um monte de requisitos para uma migração bem-sucedida. No Method360, percebemos que muitas pessoas não gastam a quantidade necessária de planejamento de tempo para as migrações e acabam tendo que voltar atrás e gastar muito tempo re-fazer coisas que deveriam ter sido feitas muito mais cedo, especialmente em as etapas de purga e limpeza de dados. Os clientes pensam que, uma vez que são transferidos para o sistema mais novo, tudo será consertado, mas acabará com um sistema lento com muitos erros. Passar o tempo para rever seus dados históricos e mestre que podem ter mudado ou não é mais necessário pode realmente acelerar seus sistemas. Para ajudar os clientes a entender tudo o que precisam para ser bem-sucedidos, criamos uma oficina gratuita. Sinta-se à vontade para dar uma olhada!
Cadastro.
Para se beneficiar plenamente do que a Comunidade SAP tem para oferecer, inscreva-se em:
A equipe da comunidade SAP.
Создал (а) Preeti Yadav, редактировал (а) Craig Cmehilмая 06, 2008.
1. Introdução.
Este documento fornece uma visão geral dos processos e metodologias de conversão de dados que podem ser usados na indústria de fabricação, que estão prontos para passar de um sistema ERP para outro sistema ERP (SAP R / 3).
O objetivo deste documento é descrever descrições detalhadas dos processos de conversão.
A conversão de dados é a conversão de uma forma de dados de computador para outro formulário com a finalidade de interoperabilidade de aplicativos ou de capacidade de usar recursos de novo sistema que requer envolvimento ativo de usuários empresariais para torná-lo correto. Geralmente, é recomendado quando uma organização se move completamente / parcialmente do sistema herdado para o novo sistema e também deseja corrigir os dados do seu antigo sistema.
2. Visão geral.
Em qualquer implementação para um novo sistema do sistema existente, a conversão de dados é essencial e crítica.
Seguindo entidades / objetos comerciais que abrangem todos os aspectos do SAP (PTP, OTC e PME) no âmbito do processo de conversão.
Item Mestre Fornecedor Mestre Cliente Mestre Números do programa.
Aberto Acordo de agendamento / Ordem de compra Pricing Abrir agendamento Acordo / Ordens de compra Abrir o preço do pedido de venda Abrir Pedidos de vendas Dados de custo padrão Saldos de inventário Bancário e banco de fornecedores Transações entre empresas Deliberações de saída Abrir AP Abrir AR.
Finanças e Controle de Dados:
CostCenter Asset Master e Transações de ativos Saldos de conta do Razão Pedidos Internos.
3. Processo de conversão.
Com base nas complexidades e múltiplas partes interessadas definidas na seção Visão geral, o processo de conversão de dados foi categorizado em 4 etapas, nomeadamente.
Extração de pré-limpeza Limpeza, enriquecimento e transformação Validação pré e pós-carregamento, Suporte de carregamento e pós-carga Assinatura.
3.1. Pré-limpeza.
Como o nome sugere, a pré-limpeza é o processo que começa antes da limpeza e foi uma das atividades críticas e importantes. Ele lida com as atividades realizadas no sistema existente / existente antes mesmo de tentar extrair dados para o novo sistema.
O usuário comercial (como o controlador de fábrica, o gerente de planta, a comunidade de compras, a comunidade de vendas, o custeio central e as finanças, a gestão da cadeia de suprimentos, etc.), juntamente com a liderança de TI (juntamente com 1 ou 2 desenvolvedores do sistema ERP existente) costumava impulsionar esse processo.
A intenção deste processo é levar o proprietário dos dados de diferentes unidades a uma plataforma comum e fazê-los concordar com a quantidade e qualidade dos dados a serem convertidos.
Durante todo o processo, as partes interessadas envolvem brain storming, discussão sobre o que deve ser feito na SAP ou o que não deveria. Nas tabelas do banco de dados pertencentes a esses objetos de negócios, isto é, Item, PO, SO etc., um campo chamado "GOSAP" foi criado. Uma vez que a decisão foi tomada sobre um PO / SO e suas partes relacionadas, esse campo costumava ser preenchido com "GOSAP" ou "NOSAP". Itens de linha com o valor de "GOSAP & quot; só procuraram processamento adicional.
Ele é executado para cada planta em uma determinada implantação para tirar um instantâneo dos dados em qualquer momento. Esta costumava ser uma atividade semanal que costumava mostrar os itens de ação para participantes interessados ou um grupo de participantes.
O relatório inclui o seguinte:
Objeto de negócios e seus atributos críticos relacionados,
Registros - Contagem de desconectas.
Porcentagem - Que parte dos dados estavam em desconectas, em comparação com a contagem total de registros para um determinado objeto de negócios.
A maioria das questões relacionadas ao negócio foi respondida com base neste relatório.
Identifique o número de peças que precisam de peças convertidas que são obsoletas, mas que possuem partes PO / SO ativas que têm custo padrão como 0 PO ativo / SOs, mas não registros de condições correspondentes, ou seja, preços Fornecedores ativos, mas sem transações (ou seja, PO) associadas a eles são clientes ativos, mas nenhuma transação (ou seja, SO) associada a eles POss estão ativos, mas os vendedores correspondentes não são mais necessários. SOs estão ativos, mas os clientes correspondentes não são mais necessários. Discrepâncias entre a venda de moeda de preços e a moeda de preço de compra.
É assim que se parece um relatório de pré-limpeza para intercompany para tratar as transações entre empresas separadamente.
A maioria das questões relacionadas entre as empresas foram respondidas com base neste relatório.
As mesmas partes são descritas de forma diferente em diferentes plantas, ou seja, o mesmo número de peça com detalhes diferentes ou a mesma descrição da peça, mas o número de peça diferente, ou seja, a combinação de descrição As discrepâncias dos preços para as mesmas peças entre 2 plantas, como a planta de venda, estão citando um preço de venda quando as unidades de compra mostrarem diferentes preço, isto é, falta de preços de preços As discrepâncias das peças entre as plantas, como uma planta, dizem que estão vendendo, mas outras estão dizendo que elas não estão recebendo ou vice-versa, ou seja, o número de linhas de PO em uma planta não está combinando com o número de SO de quem ele está comprando Preços Desajuste monetário entre as unidades de transação Unidade de medida (UoM) incompatibilidade Correspondência difícil - Quando o PO, o número da linha e as peças correspondem à planta de compras combinadas com SO, o número da linha e as peças da planta de venda Soft Match - Quando apenas o PO e as peças correspondem à compra planta com SO e número de linha da venda de plantas.
All the above mentioned analysis either for 3 rd party or intercompany were discussed in detail with the concerned data owner to arrive at a common platform so that putting junk/garbage into new system could be avoided.
The decisions based on the data owner analysis were as follows.
Convert PO/SO`s only for identified active parts Convert Vendor/Customer based on these active PO/SO`s thus making master data dependent on the transaction data Maintain standard costs for the active items Maintain condition records i. e. Pricing for every PO/SO`s except for future or release orders to customer Resolve selling and buying currency issues and adjusting the prices accordingly For intercompany, Resolve price, parts, currency, UoM discrepancies by doing workshop with both plant controller and central costing and finance team.
3.2. Extract.
After pre-cleansing was done or reaching at the final stages, Data pertaining to each business objects used to be extracted from the legacy system. The extract program was designed with the help of data and process owner considering the correct mapping of fields from legacy system to SAP system. It was developed by the existing system developer in the existing system language and was stored in the central repository called Livelink. For any deployment, the program used to be exported to respective plant database and was executed. The extracts for all the business objects used to be taken at the same time to avoid any discrepancies among the master data and transaction data. Atleast for every legacy field, a new SAP field had been added in the program so that while cleansing/enrichment, data owner compares the values without going into the existing system.
Data used to be extracted in its entirety from the old system which means no business logic in the extraction program/scripts thus reducing one level of complexities. During the pre-cleansing all the data which needed to be converted in the target system was flagged with "GOSAP/NOSAP" status. The cleansing team used to filter the relevant data based on this flag. Data were always extracted and put into flat files for further processing.
3.3. Cleansing, Enrichment and Transform.
As the title suggests, it describes 3 steps in the conversion process.
- Cleansing - Modify/make corrections in the existing data.
- Enrichment - Provide Information which are not present in the existing system but are needed by SAP system.
- Transform - Transform the cleansed/enriched data into load format using a tool called "Trillium"
Though the definition seems quite simple, it was as exhaustive as pre-cleansing cleansing. During this process of conversion completeness, correctness and accuracy of the data is one of the critical tasks which were done during this process.
After Extraction of the data for all the business objects, the data used to be formatted based on pre-defined formatting rules using Trillium and sent to business users/data owners to validate the existing information and provide the additional information (called enrichment) needed by SAP e. g. Vendors have name, address, city, zip code, Phone etc were already present in the existing system which the purchasing community were asked to validate for correctness but they were also asked to fill the information like Sales contact, Commodity that these vendors are supplying, Inco terms, Whether the vendor is minority vendor etc etc which formed the enrichment part. There were data owners for each process areas like PTP, PME and OTC and one had to follow up constantly to get the correct and accurate data from these owners.
Once the cleansed and enriched were sent back, it used to be run again in Trillium to prepare the LSMW input flat file.
For data transformation i. e. cleansing or static enrichment, Trillium was used. A lot of customization has been done in Trillium to get the data file in the format as needed by LSMW tool.
Trillium was preferred as compared to Microsoft access as the formatting tool because of the following reason:
De-duplication and identifying relationships are inbuilt features in Trillium so no manual effort for de-duplication Data Cleansing and Standardization are inbuilt again features in Trillium. So customization to certain extent would give maximum output. Handle multi plants and huge volume of data efficiently and comfortably.
During this process of conversion, data were loaded into SAP system using the upload tool from SAP called LSMW. The LSMW was customized to validate business needs especially for mandatory value attributes, dependencies, sequences and format. Hence it used to serve as the last validation juncture to identify the correctness of the data.
Every business objects had their own customized program.
3.5. Validation after Load.
Reports were developed and run in the SAP system and compare the results against what were extracted/cleansed/enriched and what got loaded to validate the correctness of the data and thus create the credibility between the data owner with the new system.
3.6. Signoff.
This exercise is done before and after the production load so that issues could be resolved before the data gets loaded in production and before the plants go live in SAP.
1 комментарий.
I notice that you do not mention open production orders in your transactional data. What is your suggestion here? My client cannot close all open production order prior to cutover so we need to find an adequate conversion method. We already have a strain on development resources which threatens to push the date, so I want to avoid any more custom code. Are you aware of any standard LSMW objects - direct input, batch input, IDoc or BAPI - that would help here?
Como planejar uma conversão de dados bem sucedida em seu movimento para a Fusion.
Jon Wakefield é consultor sênior da Oracle Line of Business na Velocity e tem mais de 16 anos de experiência funcional e técnica em produtos Oracle, incluindo PeopleSoft, Fusion e Taleo. Como parte da equipe de serviços profissionais da Velocity & rsquo; Jon é responsável pelo novo desenvolvimento e implementação de soluções Oracle. Ele pode ser alcançado em jonathan. wakefieldvelocity. cc.
Muitas organizações estão se movendo para os serviços da nuvem Oracle Fusion, aproveitando os níveis aprimorados de suporte e redução geral no custo de propriedade que o produto oferece. Se a sua organização se prepara para implementar o Fusion (clique aqui para obter algumas dicas úteis sobre como tomar essa decisão), há, é claro, uma série de fatores a serem considerados e planejados de acordo. Nesta publicação, vou me concentrar em um dos maiores, cujo impacto muitas vezes pode ser subestimado: conversão de dados Oracle.
Como o Fusion é um produto SaaS, você não terá acesso para atualizar nenhuma das tabelas e, em vez disso, deve aproveitar as ferramentas de conversão de dados que a Oracle fornece para preencher o Fusion com os dados da sua organização. A principal ferramenta com a qual você trabalhará é o FBL (File-Based Loader), e é crítico para levar o tempo inicial para entender como a ferramenta funciona e quais objetos de negócios ele suporta (clique aqui para o guia do usuário da Oracle e rsquo; lista de objetos).
Carregando dados no Oracle Fusion.
A chave para carregar com sucesso seus dados no Fusion é sobre como você extrai esses dados do seu antigo sistema. O FBL requer que você crie uma série de arquivos delimitados por tubos (.dat ou. csv) contendo todos os dados que deseja carregar no Fusion, formatados de acordo com as especificações do Oracle & rsquo; clique aqui para uma planilha de cada campo suportado e seu formato) . O FBL então importa esses arquivos e preenche as tabelas Fusion de acordo com os valores que você incluiu para cada campo. Você deve projetar um processo para preencher com atenção os arquivos que você considera necessários, certificando-se de que cada valor de campo esteja formatado e posicionado corretamente. Se você fizer isso, reduzirá seus possíveis erros de carga e removerá muitos riscos e estresse do processo de conversão de dados.
Você pode usar qualquer número de opções para conseguir isso, mas para você começar, I & rsquo; fornecerá três abordagens diretas que podem funcionar bem para você. Eles são orientados para o PeopleSoft, pois essa era minha principal experiência antes de aprender o Fusion, mas os conceitos básicos que conduzem cada um também são aplicáveis a outros sistemas de ERP.
3 Opções de Estratégia de Conversão de Dados para o Oracle Fusion Data Loading.
Se você não pensa, a Query pode acomodar o esforço de conversão da sua organização e você não quer criar SQRs, uma boa alternativa poderia ser & hellip;
Obrigado por se inscrever.
&cópia de; 2017 Velocity Technology Solutions, Inc. Todos os direitos reservados.
Comments
Post a Comment