Estratégia de conversão de dados do peoplesoft

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, além de 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 estudante.
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 em 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.

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.

Estratégia de conversão de dados do Peoplesoft
Migrar de um sistema legado para o PeopleSoft pode ser um desafio, especialmente quando você não está familiarizado com os aplicativos PeopleSoft. Há uma série de questões técnicas e funcionais, incluindo definição de requisitos, alocação de recursos, validação de dados, mapeamento de dados e gerenciamento de projetos.
PeopleSoft Data Conversion Process.
Ao converter dados de um sistema legado em um pacote como o PeopleSoft ou o Lawson Software, usamos uma abordagem em três etapas: Avaliação legada, Mapeamento de dados e Conversão. Tenha em mente que a conversão de dados é um processo iterativo. Muitas vezes, você descobrirá que os dados não foram convertidos corretamente e, em seguida, você precisará investigar o motivo, corrigir o mapa de dados e executar novamente o processo. 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. A análise dos 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. Defina regras de conversão para o campo (exemplo: a data de contratação no sistema de origem pode não ter o mesmo formato do sistema de destino e o tamanho dos dados no sistema de origem provavelmente terá um tamanho diferente do do novo sistema).
Fase II - Preparação para 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 em um formato de carregamento em lote fornecido pelo fornecedor. O processo de carregamento em lote irá migrar todos os dados no sistema legado para o formato adequado a 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 do processo de carregamento, é 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 converter dados, o que faz com que o software do aplicativo valide que os dados são precisos, tanto em formato quanto em conteúdo. Normalmente, a primeira etapa é converter tabelas usadas para validação (exemplo: departamentos da empresa e códigos de tarefa válidos). A segunda etapa é começar a converter os dados do aplicativo (por exemplo, em um sistema de Recursos Humanos, para carregar dados de funcionários). Cada etapa do processo de conversão gerará um relatório de conversão que incluirá uma seção que mostra os erros de conversão que precisam ser corrigidos antes da próxima etapa ser executada.
Fase IV - Validar o processo de conversão.
Só porque a conversão foi executada com sucesso, é importante 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 demonstrações de lucros e perdas, registros de contas a pagar, relatórios de contas a receber e relatórios de depreciação de ativos fixos serão validados 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.
Ligação Gratuita: 855.599.6740.
ESTUDOS DE CASO.
SISTEMAS DIMENSIONAIS COMO ALTERNATIVOS PARA O CONTRATANTE CARO: 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.

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, 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. OBSERVAÇÃO: SF não usa atualmente nenhum outro link ChartField (ex: & quot; AP ChartFields & quot ;, Write-off ChartFields & quot; Deferred ChartFields & quot;) ou armazena dados de campo de gráficos em outros objetos (ex: Configuração de curso ou classe, cashiering setup) Sequências de conta herdadas de 17 caracteres armazenadas em tabelas usadas como entrada para os processos de emprego do aluno da Peoplesoft devem ser convertidas em seus 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 do CU SES ganha distribuição (JOB_ERNDIST_SES_CU) ### Workforce Administration & gt; CU SES & gt; Dados de Contratação Necessária de CU SES: & quot; Adicionar Ação // Exibir Job (s) & quot; AND & quot; Criar novo emprego & quot; botões, CU SES Job Ganhos Distribuição guia UC Grad Earnings (CU_GRAD_EARNINGS) ### Ajuda Financeira & gt; CU Interfaces e Mods para FA & gt; CU Graduate Earnings Sempre que possível, as seqüências de contas de 17 caracteres ainda devem ser visualizadas no PeopleSoft como dados históricos. 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. Todas as strings de contas legadas que não podem ser convertidas em equivalentes 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 erros de conversão encontrados no teste. Para incorporar requisitos de conversão adicionais identificados na análise a jusante & amp; teste.
Necessário para uma variedade de processamento do PeopleSoft funcionar após o Plano de Contas Kauli ser ativado.
PeopleSoft Conversion Developer:
Elicia e documenta os requisitos para conversão do PeopleSoft. Faz design detalhado, consultando outros recursos técnicos conforme necessário. Código e teste unitário. Suporta teste funcional. Observa os requisitos de conversão adicionais à medida que o projeto avança. Revisa e reexecuta a conversão do PS conforme necessário.
Desenvolvedor Kuali Conversion:
Fornece mapeamento de strings de conta herdadas de 17 caracteres para strings de conta do KFS de 39 caracteres. Suporta o design de conversão do PeopleSoft e testes de unidade em relação ao seu mapeamento. Alerta o desenvolvedor de conversão PeopleSoft quando há atualizações significativas em seu mapeamento.
Equipe Funcional do PeopleSoft:
Participe na definição de requisitos. Revise os dados convertidos. Revise os erros de conversão (valores que não podem ser convertidos considerando o mapeamento KFS) e faça o acompanhamento da equipe do Plano de contas KFS. Participe no planejamento de conversão de produção.
Quadro de Funcionários do Kuali Funcionários Funcionais:
Resolva problemas se cadeias de contas de legado específicas não puderem ser convertidas usando o mapeamento de conversão do KFS. Participe no planejamento de 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 - Teste de ensaio geral. Plano de conversão de produção completo. Execute a conversão de produção.

Dashboard Dashboard.
Вложенные страницы.
Estratégia de Conversão de Dados.
Estratégia de Conversão de Dados.
Создатель Bryan Hutchinson, отредактировано, 23 de fevereiro de 2010.
NOTA - Este é um documento vivo e está 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 Kuali Financial System (KFS) para dar suporte aos principais processos de negócios. Conversões de dados bem-sucedidas são essenciais para permitir que os sistemas de contabilidade legados sejam desatribuídos e que 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 & quot; conversão de dados & quot; é usado frouxamente para descrever atividades associadas à semeadura de KFS com dados preconcebidos. Alguns dados serão carregados de fontes legadas, por exemplo, o ADW (Accounting Data Warehouse). 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 existentes do KFS. Em alguns casos, os dados não serão apenas carregados, mas serão transformados ou traduzidos com base nas 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 de negócios da Cornell e possamos utilizar todo o potencial do KFS.
Durante a vida do Projeto de Implementação do KFS, os processos e práticas de conversão de dados apoiarão fundamentalmente o cumprimento de muitos dos objetivos mais significativos do projeto, incluindo:
Definição e população do plano de contas (CoA) Implementação e teste do módulo funcional Gerenciamento do ambiente Operações do sistema Information Delivery & amp; Relatórios (ID e R)
Cada uma dessas atividades tem ciclos de vida distintos que exigirão abordagens de conversão de dados similarmente distintas. Com o tempo, essas abordagens convergirão em um caminho validado singular, semeando o banco de dados do ambiente KFS de Pré-Produção eventual.
Esse trabalho de conversão de dados oferece uma oportunidade de limpar ou corrigir dados legados incorretos, de modo que os dados semeados no KFS tenham a qualidade ideal.
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 suporta as inúmeras atividades em todo o projeto. Com o tempo, ele se tornará um dicionário de dados refinado.
Entregas 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 ir embora após a liberação de produção do KFS programada para 1/7/11, a equipe buscará oportunidades para otimizar o esforço envolvido. Conduzida e motivada por requisitos funcionais elicitados, a equipe buscará com sensatez.
assistência das soluções de fornecedores das instituições parceiras da Kuali, onde faz sentido fazê-lo em soluções prontas para uso.
Testando & amp; Validação.
The technical conversion team will be responsible for verifying that the KFS financial data has been properly converted from the legacy General Ledger according to the conversion rules supplied or approved by the functional SMEs. The functional SMEs will verify that the KFS financial data has been properly converted from the legacy General Ledger in a manner that both meets their business need and facilitates the use of KFS functionality. The ID&R team will develop solutions required for validation of converted data. Solutions will be maintained and supported by the ID&R team with assistance from CIT as appropriate. Environments will be established on an as-needed basis within which validation of data conversion can take place.
Production Support.
The data conversion process will be run as a batch process; either manually run or scheduled.
Support procedures, including contact information, will be maintained in the Project Confluence space. Functional Users have reliance on the availability of the converted data. In the event of the failure of batch jobs/scripts, users must be electronically notified/informed of the job status and be kept updated on the progress towards resolution. Customers of the data conversion process will be informed who their first point of contact (level 1) should be in the event of a suspected problem or failure Conversion scripts might be scheduled to be run automatically after the successful loading of the Accounting Data Warehouse (ADW). Conversion scripts might be manually run in an ad-hoc fashion. Problems or failures might be apparent to end users of an instance of the KFS application or users of ID&R delivered reporting solutions. Level 2 support, i. e., support for Level 1 described above, will be performed by various technical staff involved with either the data conversion process, the delivered KFS application instance, and/or the ID&R delivered reporting solutions.
Assumptions and Risks.
Premissas.
The conversion will be functionally driven with a tight feedback loop Where possible, business rules will be encoded to drive the data conversion process programmatically The Business Rules will be provided by the Functional Subject Matter Experts (SMEs) Validation of the converted data will be performed by the Project's functional stakeholders or their designees Data conversions will be run with varying frequencies depending on the articulated business need Transactions will not be converted; only monthly balances, by account and object code KEM (Kuali Endowment Module) will be available when we need it and will work together with KFS. We can enforce referential integrity (via services (e. g. KIM (Kuali Identity Management)) if necessary)
Inadequate functional participation to drive requirements to define complex business rules to validate converted data.
MITIGATION - Communicate progress regularly and escalate issues to project leadership Requirement(s) are missed or not delivered upon.
MITIGATION - Document requirements to be met, establish validation strategies based on documented requirements, define a clear issues management approach using JIRA Shared data not validated by all stakeholders.
MITIGATION - Look to the University Data Administrator to facilitate the establishment of a shared data committee similar to the PeopleSoft Shared Data Group. Detailed chart of accounts structure not finalized when needed.
MITIGATION - Escalate concerns to project leadership.