Estratégia de conversão de dados peoplesoft

Estratégia de conversão de dados do Peoplesoft
A migração de um sistema herdado para o PeopleSoft pode ser um desafio, especialmente quando você não está familiarizado com as aplicações PeopleSoft. Há uma série de questões técnicas e funcionais, incluindo a definição de requisitos, alocação de recursos, validação de dados, mapeamento de dados e gerenciamento de projetos.
Processo de conversão de dados PeopleSoft.
Ao converter dados de um sistema legado para um pacote como PeopleSoft ou Lawson Software, usamos uma abordagem de três passos: Avaliação Legada, Mapeamento de Dados e Conversão. Tenha em mente que a conversão de dados é um processo iterativo. Muitas vezes, você achará que os dados não se converteram corretamente e então você precisará investigar o motivo, corrigir o mapa de dados e executar o processo novamente. Um detalhe para precisão e paciência são fatores-chave na conversão de dados.
Fase I - Avaliação de Dados Legados & amp; Mapeamento.
O primeiro passo é analisar os dados no sistema existente e mapear os dados para o novo sistema. A maioria dos produtos de software empacotados possui processos disponíveis para carregamento em massa de dados e um processo passo a passo sobre como carregar dados. Portanto, o mapeamento de dados normalmente consiste no mapeamento para o formato do processo de carregamento em lote. Analisar os dados consiste no seguinte:
Verifique se o campo contém informações válidas e precisas. Se os dados contiverem informações codificadas (exemplo: departamento em que o funcionário trabalha, verifique se o código está no formato correto e contém dados válidos). Identifique o campo de destino para o qual os dados serão migrados. Definir regras de conversão para o campo (exemplo: a data de contratação no sistema de origem pode não ter o mesmo formato que o sistema de destino, e o comprimento de dados no sistema de origem provavelmente terá um comprimento diferente do novo sistema).
Fase II - Preparação para a conversão de dados.
Quando o mapeamento de conversão estiver concluído, é hora de converter os dados para o formato do processo de carregamento. Normalmente, isso consiste em escrever programas que convertem os dados para um formato de carga em lote fornecido pelo fornecedor. O processo de carregamento do lote irá migrar todos os dados no sistema legado para o formato apropriado para ser usado pelo processo de carregamento do fornecedor. Ao converter os dados, é importante que todos os dados sejam validados e convertidos no formato a ser usado no sistema de destino.
Fase III - Executar o Processo de Conversão.
Agora que os dados são convertidos no formato de processo de carga, é hora de executar as etapas necessárias para converter os dados. A maioria dos fornecedores de software de pacotes fornece um processo passo-a-passo para a conversão de dados, razão pela qual o software aplicativo valida que os dados são precisos, tanto em formato como em conteúdo. Normalmente, a primeira etapa é converter tabelas usadas para validação (exemplo: departamentos da empresa e códigos de tarefa válidos). O segundo passo é começar a converter os dados do aplicativo (exemplo, em um sistema de recursos humanos, para carregar os dados dos funcionários). Cada etapa do processo de conversão gerará um relatório de conversão que incluirá uma seção mostrando erros de conversão que precisam ser corrigidos antes do próximo passo ser executado.
Fase IV - Validar o processo de conversão.
Apenas porque a conversão foi executada com sucesso, é importante para você validar os dados. Isso pode ser feito através da execução de relatórios que podem ser comparados ao sistema existente (exemplo: em um sistema de pessoas, listas de funcionários de departamento ou contagens que podem ser validadas, registros de folha de pagamento e outros relatórios. Em um aplicativo financeiro, executando e validando relatórios como declarações de perda e lucro, registro de contas a pagar, relatórios de recebíveis e relatórios de depreciação de ativos fixos validadis se os dados forem convertidos corretamente).
PARA APRENDER OS “4 ERROS FEITOS NA ATUALIZAÇÃO DA PEOPLESOFT”
NOSSA LOCALIZAÇÃO.
Dimension Systems, Inc.
28525 Orchard Lake Road.
Farmington Hills, MI 48334.
Linha gratuita: 855.599.6740.
ESTUDOS DE CASO.
SISTEMAS DIMENSIONAIS COMO ALTERNATIVOS PARA O CONTRATANTE CARO: LAWSON.

Impulsionado pela PeopleSoft motivado pela MicroSoft.
Meus pensamentos sobre o setor de ERP como um todo. E uma olhada no futuro dos ERPs. Você também pode aprender sobre meus produtos neste blog. Baixe a versão de demonstração desses produtos dos links apresentados nas postagens "Demo Version of Products", "Reapply Customization" e "Oracle Fusion"
Segunda-feira, 17 de abril de 2006.
Reimplementando as Estratégias de Conversão de Dados do PeopleSoft.
Embora eu acreditei firmemente que o meu cliente atual não deveria ter optado por uma re-implementação, não pretendo espremer cada centavo do bolso. Agora é minha responsabilidade reduzir o esforço necessário neste projeto. O esforço necessário na conversão de dados definirá o projeto e eu desejo que eu o retire. Hoje eu comecei a documentar as várias estratégias que poderiam ser seguidas para a conversão de dados e espero suas valiosas sugestões para escolher o melhor desses. A complexidade com este projeto parece estar sem fim - O cliente tem uma única instância de 7,5 e ele quer dividir a instância única em duas instâncias de 8.9 diferentes (X e Y). A quantidade de dados do cliente equivale a aproximadamente 300 GB.
Reimplementação - Estratégias de Conversão de Dados.
Nessa abordagem, a conversão de dados é conseguida usando o PeopleSoft entregue programas do Application Engine personalizados para atender às nossas exigências. Para atingir nosso objetivo de migrar os dados do aplicativo do sistema Old PeopleSoft (7.5) para o nosso novo sistema (8.9), devemos primeiro atualizar o lançamento do PeopleTools do nosso sistema 7.5 para 8.46 e, em seguida, copiar os registros, os campos e os campos de registro dos nossos novos implementou o sistema 8.9 (devemos ter aplicado as personalizações para o novo sistema) no sistema 7.5. Depois disso, nós executamos o "Alter sem excluir". Copie os programas do mecanismo de aplicativos entregues pelo PeopleSoft para conversão de dados no sistema 7.5. Personalize os programas de conversão de acordo com nossos requisitos. Execute programas de conversão de dados e, em seguida, & # 8220; Alters with Deletes & # 8221 ;. Os dados do aplicativo em nosso sistema 7.5 agora podem ser migrados diretamente para o nosso novo sistema usando ferramentas de banco de dados para exportação e importação. Finalmente, podemos purificar os dados não exigidos por X e Y nos sistemas X e Y, respectivamente.
O esforço necessário para criar os scripts de conversão de dados pode ser bastante reduzido.
Os scripts de conversão de dados entregues podem ser usados ​​com pequenas modificações (Modificações são necessárias para lidar com programas de conversão de dados específicos para o caminho de atualização 7.5 a 8.8, pois esses programas terão estruturas de 7.5 + 8.8, o que temos em nosso banco de dados é 7,5 + 8,9)
O processo de conversão de dados é tratado de forma eficiente nesta abordagem e, portanto, o tempo necessário para conversão e migração é bastante reduzido.
O PeopleSoft entregou scripts de conversão de dados são específicos do caminho, portanto, o esforço necessário para combinar os dois conjuntos de programas de conversão (7.5 a 8.8 e 8.8 a 8.9) em um único programa deve ser levado em consideração.
Durante a mudança final para a produção, há uma sobrecarga adicional que exige que executemos a atualização do sistema 7.5 do PeopleTools.
A atualização do PeopleTools também exigirá migração de banco de dados de uma versão mais antiga do Oracle para a versão de banco de dados Oracle suportada.
Nesta abordagem, desenvolvemos scripts SQL que convertem os dados no sistema 7.5 para o formato de dados exigido pelo sistema 8.9. Os scripts SQL converterão dados por uma série de instruções CREATE, ALTER, UPDATE e INSERT dependendo do formato de dados exigido por 8.9. A conversão de dados acontece dentro do sistema 7.5 e, portanto, é muito eficiente. Esses scripts são criados com a ajuda dos programas de conversão de dados do PeopleSoft. Uma vez concluída a conversão de dados, podemos migrar os dados do sistema antigo para o nosso novo sistema usando ferramentas de migração de dados. A segregação de dados entre os sistemas X e Y pode ser obtida limpando os dados que não são necessários em cada um desses sistemas (os scripts devem ser desenvolvidos para essa finalidade, são instruções DELETE simples com condições específicas para limpar dados X e Y).
É removida a sobrecarga da atualização da versão do sistema 7.5 do PeopleTools durante a mudança final para a produção.
O processo de conversão de dados é otimizado migrando diretamente os dados do sistema 7.5 para 8.9 após a conversão dentro do sistema 7.5.
O esforço necessário para desenvolver os scripts de conversão é enorme.
A confiabilidade dos scripts de conversão não pode ser garantida até obtermos os resultados abrangentes do teste.
É removida a sobrecarga da atualização da versão do sistema 7.5 do PeopleTools durante a mudança final para a produção.
A segregação de dados entre os sistemas X e Y é alcançada em uma única etapa.
A migração de dados entre bancos de dados usando DBLinks não é desejável para grandes quantidades de dados, pois isso pode exigir uma grande quantidade de CACHE para armazenar os dados selecionados no banco de dados de versão antigo.
DBLinks em programas do Application Engine não são recomendados pelo PeopleSoft.
A migração de dados do banco de dados de versão antigo pode demorar muito se os Servidores estiverem em locais diferentes, este seria o cenário com sistemas X e Y.
Os dados do aplicativo são migrados de Cópia de Produção para um novo esquema no servidor de banco de dados que contém o novo banco de dados de lançamento. Os scripts de conversão de dados entregues devem ser personalizados para ler dados das tabelas que existem no esquema do banco de dados para a cópia da produção e inserir os dados nas tabelas presentes no novo esquema do banco de dados de lançamento. Isso aumentaria a eficiência da migração de dados. A segregação de dados para dados específicos X e Y é obtida com a personalização dos programas fornecidos para atender aos nossos requisitos.
A sobrecarga de atualização da versão do PeopleTools do sistema 7.5 durante a mudança final para a produção é removida.
A segregação de dados entre os sistemas X e Y é alcançada em uma única etapa.
Embora isso pareça logicamente viável, a complexidade envolvida só pode ser abordada por um DBA do PeopleSoft.
Os programas de conversão devem ser tediosamente analisados ​​e os nomes dos esquemas devem ser adicionados a cada um dos scripts de conversão.
É removida a sobrecarga da atualização da versão do sistema 7.5 do PeopleTools durante a mudança final para a produção.
A segregação de dados entre os sistemas X e Y é alcançada em uma única etapa.
A migração e a conversão podem ser alcançadas usando interfaces de componentes ou motores de aplicação somente se os dados do aplicativo estiverem presentes em um formato de arquivo plano, portanto, durante o movimento final para a produção, todos os dados no sistema 7.5 devem ser convertidos em formato de arquivo plano.
O tempo de corte exigido durante o movimento final para a produção é consideravelmente aumentado devido ao requisito de converter os dados em arquivos planos.
O processo de conversão não será tão eficiente quanto a conversão no banco de dados como no caso anterior.
Nesta abordagem, identificamos todas as tabelas que não requerem alterações estruturais para a migração de dados (as tabelas criadas pelo cliente são os melhores exemplos para esta classe de tabelas). Migre todas essas tabelas de 7.5 para 8.9 usando ferramentas de migração de banco de dados. Para as tabelas que exigem conversão, desenvolvemos os programas de conversão conforme descrito na Abordagem de implementação pura. A segregação de dados para sistemas X e Y pode ser alcançada nos scripts de conversão para tabelas que tenham uma mudança de estrutura entre o antigo e os novos lançamentos. Para as tabelas que não possuem modificações estruturais, a segregação de dados só pode ser conseguida purgando os dados que não são necessários em cada sistema individual.
A sobrecarga de atualização da versão do PeopleTools do sistema 7.5 durante a mudança final para a produção é removida.
O processo de conversão de dados é otimizado pela migração direta dos dados que não precisam de conversão.
Embora a conversão de dados seja otimizada através da migração direta de dados de tabelas que não precisam de conversão de dados, idealmente a quantidade de dados dentro dessas tabelas será apenas uma pequena porcentagem de todos os dados do aplicativo no sistema.
O tempo de corte exigido durante o movimento final para a produção é consideravelmente aumentado devido ao requisito de converter os dados em arquivos planos.
O processo de conversão não será tão eficiente quanto a conversão no banco de dados.
Por favor vote na abordagem que você estaria seguindo ou se você tiver uma abordagem melhor, me avise.
Postado por PS-GUY.
7 comentários:
Congratulo-me sinceramente por esta publicação relacionada ao trabalho, a intenção principal deste blog foi compartilhar minhas idéias e não experiências, mas desta vez eu acho que salvar o cliente tem uma prioridade maior.
Eu sinto que uma Upgrade Like Approach é melhor. A principal razão por trás desta recomendação é que você não precisa preparar os scripts de conversão que consome muito tempo. Eu sinto que o tempo necessário para desenvolver e testar esses scripts de conversão (Criar, Alterar, etc.) é muito mais do que o tempo necessário para atualizar a versão das ferramentas.
Os links DB são mais lentos e não é aconselhável como você disse.
Na abordagem de esquema, sinto que o tempo necessário para personalizar os cálculos de conversão de dados para ler de 7,5 tabelas para inserir em 8.9 tabelas irá desencorajar você a adotar essa abordagem; O mesmo acontece com as abordagens de Implementação.
(Nota: O que eu disse acima não está fora da minha experiência; é exatamente o que eu sinto)
2. A economia de esforço pode ser uma consideração menor para o cliente em comparação ao tempo de corte, por exemplo - usamos os EAs personalizados e economizamos o esforço geral, mas pedimos um corte irreal ao longo do tempo em comparação ao desenvolvimento de nossos PL-SQLs personalizados ou SQLs com muito esforço inicial, mas reduza o tempo de corte para o mínimo.
3. Os scripts de conversão de dados entregues funcionam bem durante uma atualização, mas existem pré-requisitos para a execução bem-sucedida desses programas que realizamos usando o modelo de atualização - os scripts de renomeação devem ser executados além das cópias antes da conversão de dados.
Estamos fazendo uma abordagem de atualização em duas etapas. 7,5 a 8,3 e depois 8,3 a 8,9.
Acabei de atualizar o Fin / SCM de um cliente de 7.52 para 8.9. Eu fiz uma atualização "simples" de 7.52 para 8.8 e 8.8 para 8.9.
Se você quer ser o consultor de atualização mais sofisticado - Um projeto de re-implementação fará muita justiça para sua causa. Isso é algo que descobri depois de começar a trabalhar com este projeto.
2. Processos de negócios.
3. Construindo um código de trabalho para o meu sonho.
4. Analisando todas as possibilidades de aceitação do mercado para um produto ERP da maneira MS!

Painel do painel de instrumentos.
Вложенные страницы.
Estratégia de conversão de dados.
Estratégia de conversão de dados.
Создатель Bryan Hutchinson, отредактировано фев 23, 2010.
NOTA - Este é um documento vivo e sujeito a alterações.
Definição e Visão Geral.
As conversões de dados são necessárias para transferir dados financeiros da Universidade dos sistemas legados centrais para o Sistema Financeiro Kuali (KFS) para suportar os principais processos de negócios. As conversões bem-sucedidas de dados são críticas para permitir que os sistemas de contabilidade legados sejam desativados e o processamento de transações da Universidade seja realizado a partir do sistema KFS. As conversões de dados devem ser precisas e abrangentes para permitir que os negócios da universidade sejam conduzidos com o Sistema Financeiro Kuali.
O termo "conversão de dados" é vagamente usado para descrever as atividades associadas à semeadura de KFS com dados pré-concebidos. Alguns dados serão carregados a partir de fontes legadas, por exemplo, o Accounting Data Warehouse (ADW). Outros dados serão carregados a partir de arquivos de dados fornecidos por especialistas no assunto, por exemplo, elementos de dados centrais definidos pela CoA. E outros dados podem ser extraídos de outros ambientes KFS existentes. Em alguns casos, os dados não serão apenas carregados, mas serão transformados, ou traduzidos, com base em regras de negócios que descrevem o mapeamento do legado para o KFS.
Objetivos e Benefícios.
O principal objetivo da conversão de dados é transferir dados legados para o Sistema Financeiro Kuali, aplicando regras de negócios para garantir que o KFS funcione para o processo comercial da Cornell e possamos aproveitar todo o potencial do KFS.
Ao longo da vida do Projeto de Implementação do KFS, os processos e práticas de conversão de dados apoiarão substancialmente a reunião de muitos dos objetivos mais significativos do projeto, incluindo:
Definição e população de Planos de Contas (CoA) Implementação e teste do módulo funcional Gerenciamento do meio ambiente Operações do sistema Informação Entrega & amp; Reporting (ID & R)
Cada uma dessas atividades tem ciclos de vida distintos que exigirão abordagens de conversão de dados similarmente distintas. Ao longo do tempo, essas abordagens convergem para um caminho validado singular que semeia o banco de dados do eventual ambiente de pré-produção do KFS.
Este trabalho de conversão de dados oferece uma oportunidade para limpar ou corrigir dados legados errôneos para que os dados obtidos em KFS sejam de ótima qualidade.
As colaborações com as partes interessadas de cada uma das atividades acima devem ser orientadas por requisitos funcionais.
Um mapeamento de dados do legado para o KFS deve ser mantido durante a vida de todo o projeto de implementação do KFS. No início, será um documento de trabalho que atende a infinidade de atividades em todo o projeto. Ao longo do tempo, ele se tornará um dicionário de dados refinado.
Entregáveis ​​e Ferramentas.
As primeiras versões do conjunto de ferramentas de conversão de dados dependem do código PL / SQL desenvolvido manualmente. Para o trabalho inicial do projeto, isso provou ser a abordagem mais econômica e eficiente.
Embora a necessidade de um processo de conversão de dados seja temporal, ou seja, a necessidade de isso desaparecer após o lançamento da produção do KFS agendado para 01/07/11, a equipe buscará oportunidades para agilizar o esforço envolvido. Conduzida e motivada por requisitos funcionais elicitados, a equipe buscará com sensatez.
assistência das soluções de fornecedores de instituições parceiras da Kuali, onde é sensato fazer soluções off-the-shelf.
Testando & amp; Validação.
A equipe de conversão técnica será responsável por verificar se os dados financeiros do KFS foram devidamente convertidos do Roteiro geral legado de acordo com as regras de conversão fornecidas ou aprovadas pelas PME funcionais. As PME funcionais verificam se os dados financeiros do KFS foram adequadamente convertidos do Roteiro geral do legado de uma maneira que ambos atendem às suas necessidades comerciais e facilita o uso da funcionalidade KFS. A equipe ID & amp; R desenvolverá as soluções necessárias para a validação de dados convertidos. As soluções serão mantidas e apoiadas pela equipe do ID & R com a assistência do CIT, conforme apropriado. Os ambientes serão estabelecidos de acordo com a necessidade, na qual a validação da conversão de dados pode ocorrer.
Suporte de Produção.
O processo de conversão de dados será executado como um processo em lote; seja executado manualmente ou agendado.
Os procedimentos de suporte, incluindo informações de contato, serão mantidos no espaço de Confluência do Projeto. Usuários Funcionais confiam na disponibilidade dos dados convertidos. Em caso de falha de trabalhos em lote / scripts, os usuários devem ser notificados / informados eletronicamente sobre o status do trabalho e devem ser atualizados sobre o progresso em direção à resolução. Os clientes do processo de conversão de dados serão informados sobre quem deve ser seu primeiro ponto de contato (nível 1) em caso de suspeita de problema ou falha. Os scripts de conversão podem ser programados para serem executados automaticamente após o carregamento bem-sucedido do Data Warehouse Contábil (ADW). ). Os scripts de conversão podem ser executados manualmente de maneira ad-hoc. Problemas ou falhas podem ser evidentes para os usuários finais de uma instância do aplicativo KFS ou usuários de soluções de relatório de ID & amp; R entregues. O suporte de nível 2, ou seja, o suporte para o Nível 1 descrito acima, será realizado por vários funcionários técnicos envolvidos no processo de conversão de dados, na instância do aplicativo KFS entregue e / ou nas soluções de relatórios entre ID e R.
Pressupostos e Riscos.
Premissas.
A conversão será conduzida funcionalmente com um loop de feedback apertado. Sempre que possível, as regras de negócios serão codificadas para direcionar o processo de conversão de dados de forma programática. As Regras Comerciais serão fornecidas pelos Especialistas em Matéria Funcional (PMEs). A validação dos dados convertidos será realizada por as partes interessadas funcionais do projeto ou seus designados. As conversões de dados serão executadas com freqüências variáveis, dependendo da necessidade de negócios articulada. As transações não serão convertidas; apenas saldos mensais, por conta e código de objeto KEM (Kuali Endowment Module) estarão disponíveis quando precisarmos e trabalharemos em conjunto com o KFS. Podemos impor a integridade referencial (por meio de serviços (por exemplo, KIM (Kuali Identity Management)), se necessário)
Participação funcional inadequada para gerar requisitos para definir regras comerciais complexas para validar dados convertidos.
MITIGAÇÃO - Comunicar o progresso regularmente e aumentar os problemas para a liderança do projeto Os requisitos são perdidos ou não são entregues.
MITIGAÇÃO - Requisitos do documento a serem cumpridos, estabelecer estratégias de validação baseadas em requisitos documentados, definir uma abordagem clara de gerenciamento de problemas usando o JIRA Dados compartilhados não validados por todas as partes interessadas.
MITIGAÇÃO - Procure o Administrador de Dados da Universidade para facilitar o estabelecimento de um comitê de dados compartilhado semelhante ao Grupo de Dados Compartilhados do PeopleSoft. A estrutura detalhada da tabela de contas não foi finalizada quando necessário.
MITIGAÇÃO - aumentar as preocupações com a liderança do projeto.

Painel do painel de instrumentos.
Вложенные страницы.
Estratégia de conversão PeopleSoft - maio de 2010.
Estratégia de conversão PeopleSoft - maio de 2010.
Создатель Dennis A Frederick, отредактировано мар 31, 2011.
Valores de campo do gráfico herdado são armazenados em várias tabelas no Peoplesoft. Quando o Plano de Contas da Kuali vai ao vivo em julho de 2011, algumas dessas tabelas devem conter valores de campo de gráfico Kauli equivalentes para que as funções do PeopleSoft funcionem corretamente.
Este documento define necessidades de alto nível, entregas, recursos e cronograma para essa conversão. Os detalhes serão identificados na análise subseqüente.
Requisitos de alto nível.
As cadeias de contas de legado de 17 caracteres armazenadas em tabelas que são usadas como entrada para a folha de pagamento Peoplesoft ou processos de distribuição de mão-de-obra devem ser convertidas em equivalentes Kuali de 39 caracteres. Eles devem ser convertidos para um resultado de dados consistente com a forma como os códigos de conta Kuali aparecerão quando forem atribuídos aos mesmos objetos de dados no PeopleSoft depois que o 7/2011 Kuali Financials entrar em operação. Devemos diferenciar os dados convertidos de alguma forma menor, para que possamos dizer convertidos a partir dos dados inseridos, mas caso contrário, devem ser idênticos. Para fazer isso, o desenvolvedor de conversão do PeopleSoft deve estar intimamente familiarizado com a forma como os dados da string da conta Kauli são armazenados quando inseridos através das páginas do PeopleSoft. As páginas / tabelas do Peoplesoft nesta categoria são: Distribuição de ganhos de trabalho (JOB_DATA_ERNDIST, JOB_DATA_ERNDIST_M).
Administração de mão-de-obra & gt; Job Information & gt; Dados do trabalho, & quot; Distribuição de ganhos & quot; ligação. Pagamento Adicional (ADDITIONAL_PAY1).
Folha de pagamento para a América do Norte, Employee Pay Data USA, Criar Pagamento Adicional, Pagamento Adicional. Página Earnings do orçamento do departamento (DEPT_BUDGET_ERN)
Configure o HRMS, relacionado ao produto, contabilidade de compromisso, informações de orçamento, tabela de orçamento do departamento EUA, página de configuração da tabela de dedução de ganhos do orçamento do departamento. & quot; Contas de despesas - Contabilidade sem compromisso & quot; e & quot; Contas de Responsabilidade - Contabilidade sem Compromisso & quot ;.
Configuração HRMS & gt; Relacionado ao Produto & gt; Payroll North America & gt; Deduções & gt; Tabela de Dedução. & quot; Processo & quot; aba. Configuração do Jobcode. Os códigos de trabalho são configurados com valores de código de objeto. Os valores do código do objeto legado nesta configuração devem ser convertidos em valores de código de objeto KFS equivalentes. Não é necessário converter sequências de conta herdadas de 17 caracteres armazenadas em tabelas que são produzidas a partir da folha de pagamento em lote ou processos de distribuição de mão-de-obra. Esses códigos são atribuídos cada vez que esses processos são executados. Então eles serão "convertidos" A primeira vez que esses processos resolvidos são executados. As páginas / tabelas do Peoplesoft nesta categoria são: Revisão de Distribuição de Recursos Atuais - ganhos. (PAY_CHECK_DIST_ERN)
Folha de pagamento na América do Norte & gt; Distribuição de folha de pagamento & gt; Contabilidade de compromissos EUA & gt; Revisão da distribuição de dados reais. Atualização pela atualização da Planilha por Payline Payline Obtém (Acct) Segurança.
Payroll North America & gt; Payroll Processing EUA & gt; Produzir Payroll & gt; Review Paycheck, Paycheck Earnings tab, botão de dados adicionais. Paycheck Earnings = Veja informações de ganhos detalhadas. Paycheck Summary = Ver informações de um único salário. Online Results = Veja os resultados de cálculo do processo Online Check. Essa página aparece automaticamente sempre que você envia uma verificação online para cálculo. Os valores de campo do gráfico armazenados na configuração do tipo de item devem ser convertidos em equivalentes Kuali. Configuração Inicial (ITEM_TYPE_TBL) Configuração do SACR & gt; Relacionado ao Produto & gt; Student Financials & gt; Tipos de item & gt; Tipos de itens. Guia de configuração inicial - Campos de palavras-chave (palavras-chave são usadas para procurar determinados tipos de itens.) A palavra-chave 1 representa atualmente o número de conta de 7 dígitos.) Diário Defina ChartFields (ou o futuro equivalente) (GL_INTERFACE, SSF_CF_WRKGRID_SEC, SSF_CF_WRKGRID_SUB; Tabelas: GL_INTERFACE) # ## Configuração SACR & gt; Relacionado ao Produto & gt; Student Financials & gt; Tipos de item & gt; Tipos de itens. Guia Interface GL, link Definir campos gráficos do Jrnl. NOTA: O SF não usa atualmente nenhum outro link do ChartField (ex: & quot; AP ChartFields & quot; Write-ChartFields & quot; Gráficos Diferidos & quot;) ou armazene dados do chartfield em outros objetos (ex: Configuração do curso ou da classe, cashiering configuração) As cadeias de contas legacy de 17 caracteres armazenadas em tabelas que são usadas como entrada para os processos de Emprego do Peoplesoft Student devem ser convertidas em equivalentes Kuali de 39 caracteres.
Nota: Muitos dos registros usados ​​pelo PR também são usados ​​pelo SES (ex: PAY_EARNINGS, JOB_EARNS_DIST) e podem ser endereçados lá. O trabalho da CU SES gera distribuição (JOB_ERNDIST_SES_CU) ### Administração da força de trabalho & gt; CU SES & gt; CU SES Dados de Aluguer Requeridos: & Adicionar: Ação // Ver Trabalho (s) & quot; E 'Criar novo trabalho & quot; Botões de CU SES Job Earns Distribution Alunos de Graduação de CU (CU_GRAD_EARNINGS) ### Interfaces e Mods de Auxílio Financeiro e CU para ganhos de graduação de FA & gt; CU Sempre que possível, 17 caracteres devem ser visíveis no PeopleSoft como dados de histórico. Normalmente, isso significa inserir novas linhas com data efetiva ao converter. As linhas em cada tabela a serem convertidas (todas as linhas, linhas ativas ou outros subconjuntos) serão identificadas durante a análise detalhada dos requisitos. Quaisquer cadeias de contas legadas que não podem ser convertidas em equivalentes de KFS devem ser relatadas como erros a serem investigados. A conversão do PeopleSoft precisará periodicamente ser executada novamente. Para pegar atualizações no mapeamento de conversão do gráfico de contas do KFS. Para corrigir os erros de conversão encontrados nos testes. Para incorporar requisitos de conversão adicionais identificados na análise a jusante & amp; teste.
Necessário para uma variedade de processamento do PeopleSoft para trabalhar depois que o Plano de Contas Kauli entrar em operação.
Desenvolvedor de conversão PeopleSoft:
Requisitos de documentos e documentos para a conversão do PeopleSoft. Faz projeto detalhado, consultando com outros recursos técnicos, conforme necessário. Código e teste unitário. Suporta teste funcional. Relógios para requisitos de conversão adicionais à medida que o projeto avança. Revisa e executa a conversão PS conforme necessário.
Kuali Conversion Developer:
Fornece mapeamento de cadeias de contas legacy de 17 caracteres para cadeias de contas KFS de 39 caracteres. Suporta o design de conversão PeopleSoft e o teste de unidade em relação ao seu mapeamento. Alerta o desenvolvedor de conversão PeopleSoft quando há atualizações significativas em seu mapeamento.
PeopleSoft Funcional Staff:
Participe da definição de requisitos. Revise os dados convertidos. Analise os erros de conversão (valores que não podem ser convertidos com o mapeamento KFS) e acompanhe o pessoal da Lista de Contas do KFS. Participe no planejamento da conversão de produção.
Kuali Chart of Accounts Staff Funcional:
Resolva problemas se as cadeias de contas legadas específicas não puderem ser convertidas usando o mapeamento de conversão KFS. Participe no planejamento da conversão de produção.
Início de maio de 2010 - defina os requisitos detalhados do PeopleSoft para conversão. Comece o plano de conversão de produção.
Meados de maio de 2010 - Projeto detalhado para conversão do PeopleSoft.
Junho de 2010 - Codificação e testes unitários.
Julho-dezembro de 2010 - Teste funcional, Teste com processamento downstream.
Janeiro-julho de 2011 - Testes de ensaios de vestidos. Plano completo de conversão de produção. Execute a conversão de produção.

Como planejar uma conversão de dados bem-sucedida em seu movimento para o 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 encontrado em jonathan. wakefieldvelocity. cc.
Muitas organizações estão migrando para os serviços em nuvem do Oracle Fusion, aproveitando os níveis aprimorados de suporte e a redução geral do 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 qualquer uma das tabelas e, em vez disso, deverá aproveitar as ferramentas de conversão de dados fornecidas pela Oracle 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 êxito seus dados no Fusion é como você extrai esses dados do sistema antigo. 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) . A FBL então importa esses arquivos e preenche as tabelas do 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, você reduzirá muito seus erros de carga potencial e removerá muito risco 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 ao PeopleSoft, já que essa era minha principal experiência antes de aprender o Fusion, mas os conceitos básicos que direcionam cada um são aplicáveis ​​a outros sistemas ERP também.
3 Opções de Estratégia de Conversão de Dados para o Oracle Fusion Data Loading.
Se você não acha que a Consulta pode acomodar o esforço de conversão de sua organização e você não deseja criar SQRs, uma boa alternativa poderia ser & hellip;
Obrigado por se inscrever.
&cópia de; 2018 Velocity Technology Solutions, Inc. Todos os direitos reservados.

Serviços PeopleSoft.
Ajudamos os clientes a alavancar os sistemas PeopleSoft para agilizar processos de negócios e acesso a informações # 8230;
Tagged com Peoplesoft Data Conversion Strategy.
Utilitários de conversão de dados para atualização do PeopleSoft 9.1.
Esta publicação é sobre os utilitários de conversão de dados fornecidos pela Oracle para atualizações para o PeopleSoft 9.1.
A conversão de dados é um processo chave em uma atualização do PeopleSoft, onde os dados da tabela antiga ou as colunas são convertidos em novas tabelas ou colunas. A Oracle fornece os programas de conversão na forma de Application Engine e eles são projetados para serem executados no Change Assistant para o caminho de upgrade escolhido.
Agora, se uma tabela entregue foi personalizada pela adição de campos personalizados, então é necessário analisar os programas de conversão (que geralmente são bibliotecas enormes) e tomar ações corretivas dentro do programa referenciado para que os dados não sejam perdidos. Outro desafio com conversão é melhorar o desempenho dos programas de conversão para que o tempo total de redução diminua. Com o 9.1, a Oracle trouxe recursos de análise úteis que o ajudarão não só em fazer essas ações corretivas, mas também em executar os programas de forma otimizada.
O novo EO Upgrade Framework Analysis inclui a análise das etapas de inserção, atualização e exclusão do SQL no programa de conversão de dados para determinar as tabelas de origem e de destino, o uso da coluna, os registros estatísticos e as variáveis ​​de ligação que são usadas. A informação da análise de uso da tabela é usada para determinar as dependências entre os Passos AE para que várias instâncias da conversão de dados atualizados sejam executadas em paralelo em relação a uma única informação de dependência.
Vários relatórios úteis podem ser obtidos do repositório EOUF assim que a análise estiver concluída.
& # 8211; Tabelas referenciadas Relatório: lista todas as tabelas referenciadas no Programa do mecanismo de aplicativos, incluindo a Seção, Etapa e se é uma fonte ou um alvo e o tipo de SQL (Inserir / Atualizar / Excluir) no qual é referenciado.
& # 8211; Relatório de Impactos de Customizações: Mostra a Seção / Etapas no programa Application Engine, que faz referência a tabelas com campos adicionais customizados. Com isso, podemos ir diretamente ao programa e modificar o SQL para cuidar dos campos personalizados, especialmente nas instruções Inserir.
& # 8211; Relatório de Execução por Seção: Duração: Usando o recurso AE Trace durante a conversão, este relatório mostra o tempo de execução para cada ordem de seção pelos passos de execução mais pobres no topo.
& # 8211; Relatório de Execução por Hora de Início: Este é semelhante ao relatório anterior, exceto que ele ordena pela hora de início para ver a ordem das etapas executadas.
& # 8211; Execution Report by Step/Thread/ Thread duration: Few more reports for execution timings according to the step and thread.
& # 8211; Execution Comparison Report: This report shows the execution duration for the current conversion program as compared to the previous run of data conversion.
& # 8211; Table Analysis Report: This report show how a particular application table is impacted by the create/alter scripts as well as the data conversion process during the PeopleSoft Upgrade.
Using the above has definitely helped in reducing the analysis time and also in improving the performance of the overall execution of the data conversion.
More details regarding the tables that store this information as well as the technical details are available in the Appendix Section – Using Data Conversion Utilities of the Upgrade Documentation for 9.1.