Estratégia de conversão de dados hcm da peoplesoft

Conversão de dados.
Como os cálculos previdenciários exigem um valor de carreira de dados, você deve carregar muitos dados históricos, mesmo se já estiver usando o PeopleSoft Payroll para a América do Norte e o PeopleSoft Human Resources.
Quando você move dados históricos de funcionários para o sistema PeopleSoft, você está lidando com:
Dados que não são específicos de um plano de pensão específico.
Estes são dados descritivos sobre os funcionários e seus históricos de trabalho.
Dados específicos do plano.
Isso consiste em valores calculados para componentes específicos do plano, calculados de acordo com regras planejadas específicas. Esta categoria inclui acréscimos de serviços, contas de saldo de caixa e contas contributivas de funcionários.

3.2.4 Conversão.
O objetivo da conversão de dados é converter todos os dados atuais de Recursos Humanos, Benefícios e Folha de Pagamento do Tesseract e subsistemas em PeopleSoft HRMS. A estratégia de conversão de dados se concentrará no fornecimento de flexibilidade, integridade de dados, requisitos regulamentares, processamento da Universidade, administração e necessidades de relatórios.
Âmbito de conversão.
Os dados de funcionários necessários para manter, administrar e processar informações de funcionários para Recursos Humanos, Benefícios e Folha de Pagamento serão exigidos pela PeopleSoft. A Universidade de Princeton gostaria de converter todo o histórico do mainframe para o PeopleSoft ou para um data mall para fins de relatório. Várias opções podem ser usadas para realizar isso, mas a decisão dependerá de vários fatores, incluindo o desenvolvimento de uma instância de relatório ou aplicativo de dados pequenos, o desempenho do ambiente de produção, o equilíbrio com os requisitos de negócios dos escritórios afetados.
Opção 1 Os dados do Empregado serão convertidos em duas linhas com data efetiva; a primeira linha refletirá a data original de contratação do funcionário e as informações padrão de conversão, e a segunda linha refletirá a data efetiva no momento da conversão e as informações do trabalho atual do funcionário. Essa estratégia permitirá a inserção de registros de histórico em outra fase do projeto e pressupõe que o saldo do histórico será armazenado no Oracle Tables em uma área de preparação.
Opção 2 - Empregado Os dados do trabalho serão convertidos em tantas linhas com data efetiva necessárias para manter o histórico completo. A primeira linha refletirá a data de contratação original do funcionário e a última linha refletirá a data efetiva no momento da conversão e as informações do trabalho atual do funcionário. Todas as linhas entre elas refletirão os dados reais. Isso exigirá que todas as tabelas armazenem valores históricos, como departamentos, códigos de tarefa e planos salariais que não são mais válidos. Os valores históricos aparecerão como valores inativos no PeopleSoft.
Opção 3 - Dados do Empregado serão convertidos em duas linhas com data efetiva; a primeira linha refletirá a data original de contratação do funcionário e as informações padrão de conversão, e a segunda linha refletirá a data efetiva no momento da conversão e as informações do trabalho atual do funcionário. Todos os registros do histórico de chaves serão mantidos em uma nova Tabela de Histórico, que será usada para relatórios ou visualização on-line. A tabela de histórico será atualizada com todos os novos registros de trabalho e permitirá que o relatório seja executado em relação ao histórico.
Opção 4 - Dados do Empregado serão convertidos em duas linhas com data efetiva; a primeira linha refletirá a data original de contratação do funcionário e as informações padrão de conversão, e a segunda linha refletirá a data efetiva no momento da conversão e as informações do trabalho atual do funcionário. Esses dados também serão enviados para o data mall. Todo o histórico também será convertido e mantido no data mall e todos os relatórios serão feitos no data mall. O data mall seria baseado na web e os dados seriam armazenados em tabelas do Oracle. Esse método exigirá programação para atualizar as tabelas seletivas no data mall todas as noites.
A equipe reduziu as opções de conversão para as opções 2 ou 3. Ambas as opções estão sendo analisadas de acordo com os critérios e uma decisão final será tomada até 1º de abril de 2000.
A comunidade do campus será responsável pela conversão dos dados biográficos e demográficos armazenados em dados pessoais. A estratégia confirmada é que a Campus Community entrará em produção em ou antes do RH e trará linhas com data efetiva consistentes com a estratégia de conversão de RH e os requisitos de negócios.
A ferramenta recomendada usada para conversão é SQR. Desta forma, a Universidade de Princeton pode alavancar suas habilidades técnicas em outros trabalhos de desenvolvimento de implementação. As habilidades e tecnologias necessárias para o desenvolvimento de interfaces e relatórios no PeopleSoft são SQR. Outras opções consideradas foram o Import Manager e outros fornecedores, como o PL Sequel, o Constellar, o TSI e o Informatica. Estes foram rejeitados porque exigiria que o pessoal de Princeton obtivesse uma nova habilidade que não pudesse ser reutilizada ou aproveitada para outros projetos.
Como o Tesseract tem um utilitário que cria um arquivo simples com as uniões necessárias, a estratégia é aproveitar essa ferramenta existente e criar arquivos simples. Os arquivos simples serão traduzidos em valores do PeopleSoft e, em seguida, carregados no PeopleSoft por meio do SQR.
Registro / Tabela / Painel.
Motivo da entrada manual.
Pode precisar de entrada manual para posições vagas. A equipe recomenda que aproveitemos o campo de posição do Tesseract antes da conversão e que essas informações sejam preenchidas e mantidas no Tesseract até a transição. Uma combinação de números de posição e posição deve ser usada para obter a posição atribuída.
Dean e Assistant Dean podem ser adicionados aos valores de tradução? Vai precisar.
para adicionar manualmente.
DC precisará ser adicionado manualmente. Empregados que estão fora do.
O país também pode precisar ser corrigido.
Ainda é necessário tomar uma decisão sobre quais datas serão convertidas. Como essa data será usada ainda precisa ser discutida. Pode precisar ser alterado manualmente.
Tarefa manual para adicionar quais relatórios de posição a qual supervisor. Este.
Eu informação não está no sistema atual. O PPPL mantém esse detalhe.
O sistema atual armazena o histórico para esta data. Também precisará da linha datada futura. Pode precisar de atualizações manuais. Uma solicitação de mudança aprovada que acrescente datação efetiva à data de término do compromisso deve permitir que essa informação seja convertida em PS sem intervenção manual.
Teste de Presença Substancial.
Atualmente todas as informações estão no papel. Quanta história deve ser convertida ainda precisa ser decidida. Esse teste afeta algumas centenas de pessoas.
Conversão de Recursos Humanos.
Dados Pessoais 1.
ID do funcionário, endereço.
ID irá converter de PUID, não pode carregar endereço corretamente como HR precisa de endereço local.
Apenas atual. A Universidade de Princeton não precisa de histórico em dados pessoais.
Dados Pessoais 2.
Gênero, nível de instrução mais alto, telefone, e-mail, estado civil.
O sexo pode ser um problema se o desconhecido for passado pela comunidade do campus. Data de aluguer em Tess como estudante. A comunidade universitária pode converter a partir do banco de dados pessoal - Se sim, o banco de dados de pessoas pode não ter dados limpos, pois os dados nem sempre estão atualizados.
Vai precisar de uma linha de aluguer e uma linha de conversão. Se terminado, isso substituirá a linha de conversão.
Dados Pessoais 3.
Data da morte, data de nascimento, país de nascimento.
Data de contratação e população.
Contrate alunos Converta apenas os registros atuais dos alunos e os alunos do ano anterior. Os alunos terminados dois anos antes da data de conversão não convertem o registro do trabalho.
Não terá o histórico da folha de pagamento para alunos mais velhos, porque isso será arquivado. Todos os outros podem trazer essa informação para o shopping de dados. A história de 1975 está lá fora, deveria essa informação ser convertida? Será necessário para informações de benefícios e informações W-4. Vai precisar da data de contratação original, data de conversão, mas também pode precisar da data de término e uma linha datada futura.
Não na Tess hoje. Como podemos atribuir os números de posição? Não precisa de números de posição para informações antigas? No momento, construa a posição para posições vagas, para que ela comece a ser numerada na seqüência correta. Para posições vagas, como você lida com as sobreposições? Pode precisar de trabalho manual para lidar com posições vagas, você configura um número de posição ou não? Como lidar com o DOF que não usa o número da posição. Use uma combinação de números de posição e posição para chegar à posição atribuída.
Nós construímos História?
Equipe de negócios: uso da equipe; Departamento: Contrate genérico, mas atribua com base na concessão. Localização pode precisar de um padrão. Que poderia ser derivado do departamento. O RH pode precisar padronizar o local em.
Como este campo está sendo usado? Pode Dean / Asst. Dean ser adicionado? Pode fazer manualmente, padrão para conhecido.
Converta para o campo personalizado no PeopleSoft.
Status do FLSA, Status do FICA.
Requer uma decisão de Relatório de tempos para os funcionários quinzenais.
Local do Imposto, Código da Conta, Frequência Comp.
O CD pode precisar ser feito manualmente e os funcionários do país podem precisar fazer o manual. Conta será em branco como não fazendo contabilidade de trabalho no PeopleSoft.
Componentes múltiplos do pagamento.
Quais datas podem ser convertidas e o que precisa ser feito manualmente. O número de registro de benefício será convertido com um registro zero. Se vários trabalhos forem usados, o programa de conversão criará a segunda linha.
Tarefa manual, quem reporta a qual supervisor. Vai ser difícil ligar o empregado e a posição, uma vez que não está em Tess hoje. O PPPL tem o supervisor e quem trabalha para eles.
Tess tem história.
O DOF precisa dessa data e também da linha datada do futuro.
Será configurado manualmente e mantido pelo RH.
Sufixo, precisa verificar com a equipe de alunos.
Não tem hoje; PPPL tem para conversão.
Passaporte Não e VISA info.
No papel, se tivermos. O escritório do Visa precisa verificar se necessário. Pode atualizar de uma planilha do Excel por causa do volume. A data de vencimento é em Tess e é uma data muito importante.
Mapeie comentários em Tess para este campo. Subsídio de colega institucional. Fora paga uma taxa para Princeton.
Teste de Presença Substancial.
Atualmente apenas no papel. Apenas algumas centenas de pessoas.
Quanta história deve ser convertida?
O PPPL converterá do banco de dados de 4ª dimensão do PPPL. Nenhuma conversão para a universidade. Será usado de forma limitada.
Gerenciar eventos do corpo docente.
Postos Administrativos, Honras & amp; Prêmios.
Vai converter a maior parte desta informação. Grau terminal será o grau mais alto sinalizado.
O PPPL converterá a partir do banco de dados de 4ª dimensão do PPPL.
O PPPL converterá a partir do banco de dados de 4ª dimensão do PPPL.
O sinalizador de posse será um campo personalizado no PeopleSoft.
Não é necessário para conversão. Pode converter depois de irmos ao vivo. Não estará usando no PeopleSoft, mas com outro sistema.
Plano de Ação Afirmativa.
Problema - criado pelo departamento, não como Princeton lida com AAP. Não é possível converter por departamento.
Código Ern, data de início, data de término e valor.
Segmento Tess T1 - Salário de Verão da Faculdade, Substituições de Presidente, Bolsas de Mestrado, Subsídios de Habitação, Hipoteca Imputada, Aluguel, Suplementos Salariais para Bolsistas Pós-Documento, Suplementos a Novos Planos Antigos, Indenizações.
A Credit Union é atualmente uma dedução Net Pay e Flat Dollar.
Se convertermos a união de crédito em depósito direto, precisaremos padronizar o Número de Trânsito. O número da conta pode ser SSN mais dois zeros. O Tesseract tem o valor, mas não o número da conta. A conta pode ser derivada. Conta de poupança não verificar.
Converter número de trânsito, número de conta e quantidade ou%
Traga a data de prenotização se o funcionário estiver no status prenote.
Dados fiscais do empregado.
Precisa contratar linha, ano fiscal atual - todas as mudanças e atual.
** Será o padrão para NJ. PA e DC serão padronizados pela Tess. Os alunos devem padrão para isentar do SUT.
Tratado Tributário NR Data.
NRA quantidade será baseada no grupo de pagamento.
O FICA Isento pode ser mapeado.
O ID do tratado pode ser o padrão do SETID.
Funcionários trabalhando no exterior.
Não precisa converter nada.
Localização fiscal e%
Derive de dados de impostos estaduais e distribuição sempre será o padrão de 100%
O número de dedução será mapeado para pensão alimentícia, imposto ou ordem judicial.
Os detalhes dos dados de especificação de enfeite são principalmente no papel.
Código de Dedução e Montante.
Tem todos os campos. História pode ser necessária. Nenhuma conversão na substituição geral de dedução.
A conversão deste painel depende de como a personalização será tratada.
Companhia padrão. Converta todos os contracheques do ano atual. Códigos de ganhos serão os mesmos. A conversão precisará atribuir páginas e linhas. Mapeie o grupo de pagamento. A data final e o número do cheque podem ser convertidos. Nenhum total de impostos e deduções totais no PeopleSoft. Todas as deduções antes dos impostos no PeopleSoft foram ganhos negativos na Tess. Todos os depósitos diretos têm um pagamento líquido zero na Tess. Mapeie o depósito direto da Tess na rede PeopleSoft. Precisa de unidade de ônibus, código de trabalho do departamento.
Não há dados fiscais do empregador no pagamento da Tess. Os impostos da NJ precisam ser divididos em detalhes.
Deduções, Tess tem o código e quantidade.
A taxa de penhora é um registro separado na Tess, mas incluída como parte de um registro no PeopleSoft. Não DE Regra em Tess, mas podemos deixar em branco.
Contracheque Conta Especial.
Isso precisará ser derivado. 401A tem saldos em Tess.
Converta a quantia, se disponível.
Nós podemos ter um GAP. Nós temos saldos de bolsas em TESS.
Construa a partir de detalhes, exceto para o ID do formulário.
Verifique Bals Ano-a-Data.
Converter ano fiscal e calendário e ou apenas ano civil? Pode necessitar apenas do ano civil. Mantenha-se sincronizado com o detalhe do pagamento por Mat.
Verifique o ajuste Bal.
Saldos de Saldos e Saldos de Dedução.
Nenhum MTD em Tess por Ern Codes. Pode ser derivado, mas pode não ser necessário. FISCAL ou apenas saldos de calendário? O Mat usa Saldos Fiscais para Ganhos agora. QTR pode ser suficiente e podemos não precisar de ganhos por mês. Sandy precisa de MTD. O FOCUS armazena o MTD. A TESS tem todos os saldos de QTD e YTD. Precisa de ano atual e 2 saldos do ano anterior.
Converta de Faturamento de Benefícios, Empl ID, Ded Code e Amount.
Converta o máximo possível.
Saldos Especiais do Acumulador.
Pode ser mapeado a partir de Tess.
Saldos Fiscais e 1042 Saldos.
Igual ao Saldo de Resultados, mas também precisa mapear o imposto do empregador.
A estratégia para validar as inscrições de Benefícios será executar o Snap e, em seguida, executar relatórios para localizar funcionários cujas inscrições foram encerradas e também para encontrar funcionários configurados erroneamente no plano de benefícios incorreto.
Contratar registro e registro atual.
Precisa de todas as mudanças do ano atual, mais inscrições abertas para o ano de 2001 e todas as mudanças que ocorrem após a inscrição aberta. A Universidade de Princeton também precisa de todas as mudanças de 1994 para o DataMall para auditorias, declarações HIPPO e HICFA para todos os planos de benefícios. Incluir termina no data mall.
Os encerramentos no ano atual ou no ano anterior entrariam no PeopleSoft. Além disso, traga o ano atual e o anterior para os funcionários ativos.
Não precisa da Data do Relatório HIPAA - não converta. A carta HIPAA precisa ser enviada quando o COBRA terminar. Se a data do relatório HIPAA estiver no registro, ela impedirá que outra carta seja produzida?
Data de Início da Dedução, Data de Início da Cobertura.
A Data de Início da Dedução será o padrão da Data de Início da Cobertura.
ID do provedor de saúde.
Dados Dependentes Cobertos - Relacionamento, endereço, país de nascimento, sexo.
Relacionamento também está disponível. Use o mesmo para todos os endereços. País de nascimento e localização não utilizados. Como o sexo será padronizado como desconhecido, se não houver dados, esses funcionários não poderão ser pagos ou processados ​​no Ben Admin.
Informações dependentes. deve estar no shopping de dados. O ano anterior entrará no Data Mall ou no PeopleSoft?
Dados incorretos e falta de comparência para futuras contratações de DOF ocasionam problemas. O DOF pode ir diretamente para o Orçamento de Ensino para adicioná-los ao Orçamento e esperar por bons dados antes de entrar no PeopleSoft?
Estado civil do cônjuge.
Use a mesma data que o estado civil do funcionário Dados Pessoais.
Data do status do aluno.
Data da Morte para Dependentes.
Tela de comentário em Tess. Não converta, mas use daqui para frente.
Não converta o Beneficiário para os Planos de Benefícios de Vida, mas pode ser inserido manualmente depois da ativação. Há um campo em Tess que não está sendo usado no momento, mas pode ser atualizado no Tesseract antes da conversão.
A personalização pode determinar as regras de DST ou o Ben Admin pode determinar os planos de benefícios.
2 planos em Tess precisarão ser combinados em um plano.
A conversão depende se o processo de saída estiver no escopo da conversão.
TIAA ou TESS (questão de tempo)
Há um cálculo que precisaria ocorrer se a alimentação for direta da TIAA. A data da conversão determinará a origem.
Juramento Anual & amp; Deduções tomadas.
Anterior ano. & amp; Ano atual No PeopleSoft.
Carregue para um plano 7X ou 7Y, mas traga os funcionários como terminados no plano. Grupo PRU.
Inclua funcionários COBRA, aposentados, etc. Existe um código no PeopleSoft.
Saldos e Pagamento.
Os pagamentos da conta e os saldos estão em Empréstimos & amp; Recebíveis. Contas estão em Tess.
Também convertemos todos os encargos e pagamentos do ano atual ou ano anterior? Isso depende se passamos ou não para L & R.
O que queremos converter, se houver alguma coisa?
A ligação entre o Cônjuge sobrevivente e o Funcionário falecido está em um campo de forma livre.
Benefícios precisa de informações de relatórios. por 6 anos. Os funcionários falecidos podem ser convertidos no PeopleSoft ou no Data Mall? Que data nós desenharíamos a linha?
Não crie um evento COBRA para finalizações no PeopleSoft no momento da conversão.
Current & amp; Registros do ano anterior no PeopleSoft e em todos os outros no data mall.

Impulsionado pela PeopleSoft motivado pela MicroSoft.
Meus pensamentos sobre a indústria de ERP como um todo. E uma espiada no futuro dos ERPs. Você também pode aprender sobre meus produtos neste blog. Baixe a versão demo destes produtos a partir dos links apresentados nos posts "Versão de Demonstração dos Produtos", "Reaplicar Customização" e "Oracle Fusion"
Segunda-feira, 17 de abril de 2006.
Reimplementando as Estratégias de Conversão de Dados do PeopleSoft.
Embora eu acredite fortemente que meu atual cliente não deveria ter optado por uma reimplementaçã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 comecei a documentar as várias estratégias que poderiam ser seguidas para a conversão de dados e aguardo as suas sugestões valiosas para escolher o melhor deles. A complexidade com este projeto parece nunca terminar. O cliente tem uma única instância 7.5 e ele quer dividir a instância única em duas instâncias 8.9 diferentes (X e Y). A quantidade de dados do cliente é de aproximadamente 300 GB.
Reimplementação - Estratégias de Conversão de Dados.
Nessa abordagem, a conversão de dados é obtida usando os programas entregues do Application Engine da PeopleSoft personalizados para atender às nossas necessidades. Para alcançar nosso objetivo de migrar os dados do aplicativo do sistema PeopleSoft antigo (7.5) para o nosso novo sistema (8.9), devemos primeiro atualizar a versão do PeopleTools do nosso sistema 7.5 para a 8.46 e copiar os registros, campos e campos de registro do nosso novo sistema. implementado 8.9 (Devemos ter aplicado o sistema de personalizações para o novo sistema) para o sistema 7.5. Depois disso, nós executamos o "Alter sem excluir". Copie os programas do mecanismo de aplicativo entregues pelo PeopleSoft para conversão de dados no sistema 7.5. Personalize os programas de conversão para atender às nossas necessidades. Execute programas de conversão de dados e, em seguida, "Alters with Deletes & # 8221 ;. Os dados do aplicativo em nosso sistema 7.5 agora podem ser migrados diretamente para 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 eficientemente nessa abordagem e, portanto, o tempo necessário para conversão e migração é reduzido consideravelmente.
Os scripts de conversão de dados entregues do PeopleSoft são específicos do caminho, portanto, o esforço necessário para mesclar 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 nos obriga a executar a atualização do PeopleTools do sistema 7.5.
A atualização do PeopleTools também exigirá a migração do banco de dados de uma versão anterior do Oracle para a versão suportada do banco de dados Oracle.
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 os 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 entregues pelo PeopleSoft. Quando a conversão de dados estiver concluída, podemos migrar os dados do sistema antigo para o 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).
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 do sistema de 7,5 para 8,9 após a conversão no 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.
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.
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 manter os dados selecionados do antigo banco de dados de versões.
DBLinks em programas do Application Engine não são recomendados pelo PeopleSoft.
A migração de dados do antigo banco de dados de liberação pode ser demorada se os Servidores estiverem em locais diferentes, esse seria o cenário com os sistemas X e Y.
Os dados do aplicativo são migrados da Cópia de Produção para um novo esquema no servidor de banco de dados que contém o novo banco de dados de liberação. Os scripts de conversão de dados entregues devem ser customizados para ler dados das tabelas que existem no esquema do banco de dados para cópia de produção e inserir os dados nas tabelas presentes no novo esquema do banco de dados de liberação. 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 resolvida por um DBA PeopleSoft.
Os programas de conversão devem ser tediosamente analisados ​​e os nomes de esquema devem ser adicionados a cada um dos scripts de conversão.
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.
Migração e conversão podem ser obtidas usando Interfaces de Componentes ou Mecanismos de Aplicação somente se os dados da aplicação estiverem presentes em um formato de arquivo simples, portanto durante a movimentação final para a produção todos os dados no sistema 7.5 devem ser convertidos em formato de arquivo simples.
O tempo de corte necessário durante o movimento final para a produção é consideravelmente aumentado devido ao requisito de converter os dados em arquivo simples.
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 nenhuma alteração estrutural para a migração de dados (as tabelas criadas pelo cliente são os melhores exemplos para essa 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 requerem 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 obtida nos scripts de conversão para tabelas que possuem uma alteração de estrutura entre as versões antiga e nova. Para as tabelas que não possuem modificações estruturais, a segregação de dados só pode ser obtida eliminando 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 pela migração direta de dados de tabelas que não precisam de nenhuma conversão de dados, o ideal é que a quantidade de dados nessas tabelas represente apenas uma pequena porcentagem de todos os dados do aplicativo no sistema.
O tempo de corte necessário durante o movimento final para a produção é consideravelmente aumentado devido ao requisito de converter os dados em arquivo simples.
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:
Eu sinceramente peço desculpas por este trabalho relacionado post, a principal intenção deste blog foi compartilhar minhas idéias ao invés de 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, 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 que leva para atualizar a versão das ferramentas.
Links DB são mais lentos e não é aconselhável como você disse.
Na abordagem do esquema, sinto que o tempo que leva para personalizar os scipts de conversão de dados para ler de 7.5 tabelas para inserir em 8.9 tabelas 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 um upgrade "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 reimplementação fará muita justiça à 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!

Dashboard Dashboard.
Вложенные страницы.
Estratégia de conversão do PeopleSoft - maio de 2010.
Estratégia de conversão do PeopleSoft - maio de 2010.
Создатель Dennis A Frederick, отредактировано 31 de março de 2011.
Valores de campo do gráfico herdado são armazenados em várias tabelas no Peoplesoft. Quando o Plano de Contas Kuali for lançado em julho de 2011, algumas dessas tabelas deverão conter valores de campo de gráfico Kauli equivalentes para que as funções do PeopleSoft funcionem corretamente.
Este documento define necessidades, entregas, recursos e agendamento de alto nível para essa conversão. Detalhes serão identificados na análise subseqüente.
Requisitos de alto nível.
Cadeias de contas herdadas de 17 caracteres armazenadas em tabelas que são usadas como entrada para os processos de folha de pagamento ou de distribuição de mão-de-obra do Peoplesoft devem ser convertidas em seus equivalentes Kuali de 39 caracteres. Eles devem ser convertidos em um resultado de dados consistente com a aparência dos códigos de conta do Kuali quando forem atribuídos aos mesmos objetos de dados no PeopleSoft após o 7/2011 Kuali Financials ir ao ar. Devemos diferenciar os dados convertidos de alguma forma menor, para que possamos dizer convertidos a partir dos dados inseridos, mas caso contrário, eles devem ser idênticos. Para fazer isso, o desenvolvedor da conversão do PeopleSoft deve estar intimamente familiarizado com a forma como os dados da string da conta do Kauli são armazenados quando inseridos por meio das páginas do PeopleSoft. As páginas / tabelas do Peoplesoft nessa categoria são: Job Earnings Distribution (JOB_DATA_ERNDIST, JOB_DATA_ERNDIST_M).
Administração da força de trabalho & gt; Informações do trabalho & 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)
Configurar HRMS, produtos relacionados, 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 ;.
Configurar HRMS & gt; Relacionado com produtos & gt; Folha de pagamento na América do Norte & gt; Deduções & gt; Tabela de dedução. "Processo" aba. Configuração do Jobcode. Os códigos de tarefas são configurados com valores de código de objeto. Os valores do código de objeto herdado 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 a cada vez que esses processos são executados. Então eles serão "convertidos" a primeira vez que esses processos corrigidos são executados. As páginas / tabelas do Peoplesoft nesta categoria são: Revisar Distribuição de Actuals - 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 por Atualização de Paysheet por Payline Payline Earns (Acct) Security.
Folha de pagamento na América do Norte & gt; Processamento da folha de pagamento EUA & gt; Produzir folha de pagamento & gt; Revisar folha de pagamento, guia Salários de pagamento e botão de dados adicionais. Ganhos de salário = Ver informações detalhadas sobre ganhos. Paycheck Summary = Ver informações de um único salário. Resultados Online = Ver resultados de cálculos do processo de Verificação Online. Essa página aparece automaticamente sempre que você envia uma verificação online para cálculo. Os valores do campo 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 com produtos & gt; Finanças do estudante & gt; Tipos de itens & gt; Tipos de itens. Guia Configuração inicial - Campos de palavras-chave (Palavras-chave são usadas para pesquisar tipos de itens específicos. A palavra-chave 1 representa atualmente o número da conta de 7 dígitos.) Journal Set ChartFields (ou o equivalente futuro) (GL_INTERFACE, SSF_CF_WRKGRID_SEC, SSF_CF_WRKGRID_SUB; Tabelas: GL_INTERFACE) # ## Configuração SACR & gt; Relacionado com produtos & gt; Finanças do estudante & gt; Tipos de itens & gt; Tipos de itens. Guia Interface GL, link Definir campos gráficos do Jrnl. NOTE: SF does not currently use any other ChartField link (ex: "AP ChartFields", "Write-off ChartFields", "Deferred ChartFields") or store chartfield data on other objects (ex: Course or Class setup, cashiering setup) 17 character legacy account strings stored on tables that are used as input to the Peoplesoft Student Employment processes must be converted to their 39 character Kuali equivalents.
Note: Many of the records used by PR are also used by SES (ex: PAY_EARNINGS, JOB_EARNS_DIST) and may be addressed there. CU SES Job Earns Distribution (JOB_ERNDIST_SES_CU) ### Workforce Administration>CU SES> CU SES Required Hire Data: "Add Action//View Job(s)" AND "Create new job" buttons, CU SES Job Earns Distribution tab CU Grad Earnings (CU_GRAD_EARNINGS) ### Financial Aid>CU Interfaces and Mods for FA>CU Graduate Earnings Whenever possible, 17 character account strings should still be viewable in PeopleSoft as history data. Typically, that means inserting new effective dated rows when converting. The rows in each table to be converted (all rows, active rows, or other subsets) will be identified during detailed requirements analysis. Any legacy account strings that can't be converted to KFS equivalents must be reported as errors to be investigated. The PeopleSoft conversion will periodically need to be rerun. To pick up updates to the KFS chart of accounts conversion mapping. To correct conversion errors found in testing. To incorporate additional conversion requirements identified in downstream analysis & testing.
Needed for a variety of PeopleSoft processing to work after the Kauli Chart of Accounts go live.
PeopleSoft Conversion Developer:
Elicits and documents requirements for PeopleSoft conversion. Does detailed design, consulting with other technical resources as necessary. Code and unit test. Supports functional test. Watches for additional conversion requirements as the project progresses. Revises and reruns PS conversion as necessary.
Kuali Conversion Developer:
Provides mapping from 17 character legacy account strings to 39 character KFS account strings. Supports PeopleSoft conversion design and unit testing in regards to their mapping. Alerts PeopleSoft conversion developer when there are significant updates to their mapping.
PeopleSoft Functional Staff:
Participate in requirements definition. Review converted data. Review conversion errors (values that can't be converted given KFS mapping) and follow up KFS Chart of Accounts staff. Participate in production conversion planning.
Kuali Chart of Accounts Functional Staff:
Resolve issues if specific legacy account strings can't be converted using KFS conversion mapping. Participate in production conversion planning.
Early May 2010 - Define PeopleSoft detailed requirements for conversion. Begin production conversion plan.
Mid-Late May 2010 - Detailed design for PeopleSoft conversion.
June 2010 - Coding and unit testing.
July-December 2010 - Functional testing, Testing with downstream processing.
January-July 2011 - Dress rehearsal testing. Complete production conversion plan. Execute production conversion.

Peoplesoft hcm data conversion strategy

Migrating from a legacy system to PeopleSoft can be challenging, especially when you are unfamiliar with the PeopleSoft applications. There are a number of technical and functional issues including requirements definition, resource allocation, data validation, data mapping and project management.
PeopleSoft Data Conversion Process.
When converting data from a legacy system to a package like PeopleSoft or Lawson Software, we use a three-step approach: Legacy Evaluation, Data Mapping and Conversion. Keep in mind that data conversion is an iterative process. Often you will find that data did not convert properly and you will then need to investigate the reason, correct the data map and rerun the process. A detail to accuracy and patience are key factors when converting data.
Phase I – Legacy Data Evaluation & Mapping.
The first step is to analyze the data in the existing system then map the data to the new system. Most packaged software products have processes available for bulk loading of data and a step-by-step process regarding how to load data. Therefore, data mapping typically consists of mapping to the batch load process format. Analyzing the data consists of the following:
Verify that the field contains valid and accurate information. If the data contains coded information (example: department where the employee works verify that the code is in the correct format and contains valid data). Identify the target field where the data will migrate to. Define conversion rules for the field (example: hire date in the source system may not have the same format as the target system, and the data length in the source system most likely will have a different length than the new system).
Phase II – Preparation for Data Conversion.
Once the conversion mapping is completed, it is time to convert the data to the load-process format. Typically, this consists of writing programs that convert the data to a batch load format provided by the vendor. The batch load process will migrate all of the data in the legacy system into the proper format to be used by the vendor’s load process. When converting the data, it is important that all of the data is validated and converted into the format to be used in the target system.
Phase III – Execute the Conversion Process.
Now that the data is converted into the load-process format, it is time to execute the steps required to convert the data. Most package software vendors provide a step-by-step process for converting data, the reason being to have the application software validate that the data is accurate, both in format and content. Typically, the first step is to convert tables used for validation (example: company departments and valid job codes). The second step is to begin converting the application data (example, in a Human Resources system, to load employee data). Each step of the conversion process will generate a conversion report that will include a section showing conversion errors that need to be corrected before the next step is run.
Phase IV – Validate the Conversion Process.
Just because the conversion has executed successfully, it is important for you to validate the data. This can be accomplished by executing reports that can be compared to the existing system (example: in a people system, department employee lists or counts that can be validated, payroll registers and other reports. In a financials application, executing and validating reports such as profit & loss statements, payables register, receivables reports and fixed asset depreciation reports will validate if the data is converted properly).
TO LEARN THE “4 MISTAKES OFTEN MADE WHEN UPGRADING PEOPLESOFT”
OUR LOCATION.
Dimension Systems, Inc.
28525 Orchard Lake Road.
Farmington Hills, MI 48334.
Toll Free: 855.599.6740.
ESTUDOS DE CASO.
DIMENSION SYSTEMS AS ALTERNATIVE TO EXPENSIVE CONTRACTOR: LAWSON.

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, Jon é responsável pelo novo desenvolvimento e implementação de soluções Oracle. Ele pode ser encontrado em jonathan. wakefield@velocity. 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 está se preparando para implementar o Fusion (clique aqui para obter algumas dicas úteis sobre como tomar essa decisão), há, é claro, vários fatores a serem considerados e planejados adequadamente. Neste post, vou me concentrar em um dos grandes, 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 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 é essencial ter tempo para entender como a ferramenta funciona e quais objetos de negócios ela suporta (clique aqui para o guia do usuário da Oracle e 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. A FBL exige que você crie uma série de arquivos delimitados por pipe (.dat ou. csv) contendo todos os dados que você deseja carregar para o Fusion, formatados de acordo com as especificações da Oracle (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 criar um processo para preencher cuidadosamente os arquivos que julgar necessários, certificando-se de que cada valor de campo seja 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 começar, eu fornecerei 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 da 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.