Estratégia de conversão de dados peoplesoft

Conversão de dados.

Como os cálculos de aposentadoria requerem dados de carreira, você deve carregar muitos dados históricos mesmo se você já estiver usando o PeopleSoft Payroll para a América do Norte e PeopleSoft Human Resources.

Quando você move os dados dos funcionários históricos para o sistema PeopleSoft, você está lidando com:

Dados que não são específicos de um plano de pensão específico.

Este é um dado descritivo sobre os empregados e suas histórias de trabalho.

Dados que são específicos do plano.

Isso consiste em valores calculados para componentes específicos do plano, calculados de acordo com as regras específicas do plano. Esta categoria inclui o acréscimo do serviço, as contas do saldo de caixa e as contas contributivas dos empregados.

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 de Tesseract e subsistemas em PeopleSoft HRMS. A estratégia de conversão de dados incidirá no fornecimento de flexibilidade, integridade dos dados, requisitos regulamentares, processamento da Universidade, administração e necessidades de relatórios.

Escopo da conversão.

Os dados dos funcionários necessários para manter, administrar e processar informações dos funcionários para recursos humanos, benefícios e folha de pagamento serão necessários pelo PeopleSoft. A Universidade de Princeton gostaria de converter todo o histórico do mainframe em PeopleSoft ou em um centro de dados para fins de relatórios. Uma série de opções podem ser usadas para realizar isso, mas a decisão dependerá de uma série de fatores, incluindo desenvolvimento de uma instância de relatório ou aplicativo de datamall, desempenho do ambiente de produção, equilíbrio com os requisitos de negócios dos escritórios afetados.

Opção 1 Os dados do trabalho do empregado serão convertidos em duas linhas efetivamente datadas; a primeira linha refletirá a data de contratação original do empregado 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 atuais do trabalho do empregado. Essa estratégia permitirá a inserção de registros de histórico em outra fase do projeto e assume que o saldo do histórico será armazenado nas Tabelas Oracle em uma área de teste.

Opção 2 - Os dados do trabalho do empregado serão convertidos em tantas linhas efetivas datadas necessárias para manter o histórico completo. A primeira linha refletirá a data de contratação original do empregado e a última linha refletirá a data efetiva no momento da conversão e a informação atual do empregado sobre o trabalho. Todas as linhas entre elas refletirão dados reais. Isso exigirá que todas as tabelas mantenham valores históricos como departamentos, códigos de trabalho 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 - Empregado Os dados do trabalho serão convertidos em duas linhas efetivamente datadas; a primeira linha refletirá a data de contratação original do empregado 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 atuais do trabalho do empregado. Todos os registros históricos históricos 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 tarefas e permitirá que relatórios sejam executados em relação ao Histórico.

Opção 4 - Dados do trabalho do empregado serão convertidos em duas linhas efetivamente datadas; a primeira linha refletirá a data de contratação original do empregado 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 atuais do trabalho do empregado. Estes dados também serão enviados para o centro de dados. Todo o histórico também será convertido e mantido no centro de dados e todos os relatórios serão feitos contra o centro de dados. O centro de dados seria baseado na web e os dados seriam armazenados nas tabelas do Oracle. Este método exigirá programação para atualizar tabelas seletivas no centro de dados 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 revisadas de acordo com os critérios e uma decisão final será tomada até 1º de abril de 2000.

A Comunidade Campus será responsável pela conversão dos dados biográficos e demográficos armazenados em Dados Pessoais. A estratégia confirmada é que a Comunidade Campus entrará em produção em ou antes da RH e trará linhas efetivas datadas 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 aproveitar suas habilidades técnicas em outros trabalhos de desenvolvimento de implementação. As habilidades e tecnologia necessárias para o desenvolvimento de interfaces e relatórios no PeopleSoft são SQR. Outras opções consideradas foram Import Manager e fornecedores de terceiros, como PL Sequel, Constellar, TSI e Informatica. Estes foram rejeitados porque exigiria que o pessoal da Princeton ganhasse uma nova habilidade que não poderia ser reutilizada ou alavancada para outros projetos.

Uma vez que o Tesseract possui um utilitário que cria um arquivo plano com as junções necessárias, a estratégia é aproveitar esta ferramenta existente e criar arquivos planos. Os arquivos planos serão então traduzidos para valores do PeopleSoft e depois carregados no PeopleSoft através do SQR.

Record / Table / Panel.

Razão para a entrada manual.

Pode precisar de entrada manual para posições vagas. A equipe recomenda que aproveitamos o campo de posição de Tesseract antes da conversão e que essa informação seja preenchida e mantida em Tesseract até o tempo de reposição. Uma combinação de números de departamento e posição deve ser usada para obter a posição atribuída.

Dean e Dean assistente devem ser adicionados aos valores de tradução? Vai precisar.

para adicionar manualmente.

DC terá de ser adicionado manualmente. Empregados que estão fora do.

O país também pode ser corrigido.

A decisão ainda precisa ser feita em que datas serão convertidas. A forma como essa data será usada ainda precisa ser discutida. Pode precisar ser alterado manualmente.

Tarefa manual para adicionar o relatório de posição a qual supervisor. Este.

As informações da I não estão no sistema atual. PPPL mantém esse detalhe.

O sistema atual armazena o histórico para essa data. Também precisará a linha datada no futuro. Pode precisar de atualizações manuais. Um pedido de alteração aprovado que adiciona namoro efetivo à data de término da consulta deve permitir que essas informações sejam convertidas em PS sem intervenção manual.

Teste de presença substancial.

Atualmente, toda a informação está em papel. Qual é a quantidade de história que deve ser convertida ainda precisa ser decidida. Este teste afeta algumas centenas de pessoas.

Conversão de recursos humanos.

Dados pessoais 1.

ID do empregado, endereço.

O ID converterá do PUID, pode não carregar o endereço corretamente, pois o RH precisa de um endereço local.

Somente atual. Princeton University não precisa de histórico em dados pessoais.

Dados pessoais 2.

Gênero, Nível de Educação Máximo, Telefone, E-mail, Estado civil.

O gênero pode ser um problema se desconhecido é passado pela comunidade do campus. Data de contratação em Tess como estudante. A Comunidade do Campus pode converter do Banco de Dados da Pessoa - Se assim for, o banco de dados da Pessoa pode não ter dados limpos, pois os dados nem sempre estão atualizados.

Será necessária uma linha de aluguel e uma linha de conversão. Se encerrado, isso irá substituir a linha de conversão.

Dados pessoais 3.

Data de falecimento, Data de nascimento, País de nascimento.

Contrato Data e População.

Contratar estudantes Apenas converta os registros atuais dos alunos e os alunos do ano anterior. Os alunos terminaram dois anos antes da data de conversão não converter o registro do trabalho.

Não terá o histórico de folha de pagamento para estudantes mais velhos, porque isso será arquivado. Todos os outros podem trazer essa informação para o centro de dados. A história de 1975 está por aí, se essa informação for convertida? Será necessário para informações de benefícios e informações W-4. Precisará da data original de contratação, data de conversão, mas também pode precisar da data de rescisão e de uma linha datada no futuro.

Não está hoje em Tess. Como atribuímos os números de posição? Não precisa de números de posição para informações antigas? No momento, crie a posição para cargos vagos para que ele comece a numerar na seqüência certa. Para cargos vagos, 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 departamento e posição para obter a posição atribuída.

Construímos História?

Pessoal de negócios: uso da equipe; Departamento: contratar genéricos, mas atribuir com base na concessão. O local pode precisar de um padrão. O que poderia ser derivado do departamento. O RH pode precisar definir a localização na.

Como esse campo está sendo usado? Dean / Asst. Dean ser adicionado? Pode ser feito manualmente, por padrão, conhecido.

Converta em campo personalizado no PeopleSoft.

Status FLSA, Status FICA.

Requer uma decisão de Relatórios de tempo para os funcionários quinzenais.

Localização do imposto, Código da Conta, Frequência Comp.

DC pode precisar ser feito manualmente e os funcionários que o país pode precisar fazer o manual. A conta ficará em branco na medida em que não faz contabilidade trabalhista 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 forem utilizados vários trabalhos, o programa de conversão criará a segunda linha.

Tarefa manual, que relata qual supervisor. Será difícil ligar o funcionário e a posição, uma vez que não está em Tess hoje. PPPL tem o supervisor e quem trabalha para eles.

Tess tem história.

O DOF precisa desta data e também a linha datada no futuro.

Será configurado manualmente e mantido por RH.

Sufixo, precisa verificar com a equipe de Estudantes.

Não tem hoje; PPPL tem para conversão.

Passaporte Não e informações de VISA.

Em papel se tivermos. O escritório de visto precisa verificar se necessário. Pode atualizar a partir de uma planilha do Excel por causa do volume. A data de validade está em Tess e é uma data muito importante.

Posicione comentários no Tess para este campo. Subsídio institucional. Fora paga uma taxa para Princeton.

Teste de presença substancial.

Atualmente, apenas em papel. Apenas algumas centenas de pessoas.

Qual a história que deve ser convertida?

PPPL converterá do banco de dados de dimensão PPPL 4th. Nenhuma conversão para a Universidade. Será usado em uma base limitada.

Gerenciar Eventos de Faculdade.

Posts Administrativos, Honras e Prêmios.

Converte a maioria dessas informações. O grau de terminal será o mais alto nível marcado.

PPPL converterá do banco de dados de dimensão PPPL 4th.

PPPL converterá do banco de dados de dimensão PPPL 4th.

A bandeira de propriedade será um campo personalizado no PeopleSoft.

Não é necessário para a conversão. Podemos converter depois de entrar em frente. Não vai usar no PeopleSoft, mas com outro sistema.

Plano de Ação Afirmativa.

Problema - Configurado por departamento, e não como o Princeton lida com o AAP. Não é possível converter pelo departamento.

Código Ern, Beg Date, End Date e Amount.

Segmento Tess T1 - Salário de Verão da Faculdade, Subsídios do Presidente, Salários Mestres, Subsídios de Habitação, Hipoteca Imputada, Aluguel, Suplementos Salariais para Associados do Post Doc, Suplementos do Novo Plano Novo, Saldo de Partida.

Credit Union é atualmente uma dedução Net Pay e Flat Dollar.

Se convertermos a união de crédito em depósito direto, precisaremos o número de trânsito padrão. O número da conta pode ser SSN mais dois zeros. Tesseract tem o valor, mas não o número da conta. A conta pode ser derivada. Conta de poupança não verificando.

Converter número de trânsito, número de conta e valor ou%

Traga a data de pré-decisão se o empregado estiver no status de prenote.

Dados do imposto sobre os empregados.

Necessita de alugar linha, ano fiscal atual - todas as mudanças e atuais.

** Será padrão para NJ. PA e DC serão padrão de Tess. Os alunos devem usar o padrão de Excepto do SUT.

Dados NR do Tratado Tributário.

NRA montante será baseado em Pay Group.

FICA Exempt pode ser mapeado.

O ID do Tratado poderia ser padrão do SETID.

Funcionários que trabalham no exterior.

Não precisa converter nada.

Situação do imposto local e%

Derivar dos Dados Fiscais do Estado e Distribuição sempre será padrão para 100%

O número da dedução será mapeado para apoio à criança, tributação ou resgate.

Os detalhes dos detalhes da especificação são principalmente em papel.

Código de Dedução e Montante.

Tem todos os campos. A história pode ser necessária. Nenhuma conversão sobre Substituição de Dedução Geral.

A conversão deste painel depende da forma como a personalização será tratada.

Empresa padrão. Converta todos os cheques de pagamento do ano atual. Os códigos de ganhos serão os mesmos. A conversão terá que atribuir páginas e linhas. Mapear o Grupo de Pagamento. Data final e o número de verificação pode ser convertido. Não há impostos totais e deduções totais no PeopleSoft. Todas as deduções pré-impostos no PeopleSoft foram ganhos negativos em Tess. Todos os depósitos diretos têm zero salário líquido em Tess. Posicione o depósito directo da Tess na rede PeopleSoft. Precisa de Unidade de Ônibus, Código de Trabalho do Departamento.

Não há dados de impostos do empregador no cheque de pagamento da Tess. Os impostos de NJ precisam dividir os detalhes.

Deduções, Tess tem o código e o montante.

Garnishment Fee é um registro separado em Tess, mas incluído como parte de um registro no PeopleSoft. Não DE Rule em Tess, mas podemos deixar isso em branco.

Pay-Checkack Special Accum.

Isso deve ser derivado. 401A possui saldos em Tess.

Converta o valor se disponível.

Podemos ter um GAP. Nós temos saldos de bolsa no TESS.

Construa de detalhes, exceto o Form ID.

Verifique o valor de Bals até o presente ano.

Converta o ano fiscal e civil e ou apenas o ano civil? Pode precisar apenas do Ano do calendário. Mantenha-se em sincronia com o detalhe do salário por Mat.

Verifique o ajuste de Bal.

Saldos de ganhos e saldos de dedução.

Não há MTD em Tess por Ern Codes. Poderia ser derivado, mas pode não ser necessário. FISCAL ou apenas saldos do calendário? Mat usa saldos fiscais para ganhos agora. O QTR pode ser suficiente e talvez não precisemos de ganhos por Mês. Sandy precisa de MTD. FOCUS armazena MTD. O TESS possui todos os saldos QTD e YTD. Precisa do ano atual e dos saldos do ano anterior.

Converta de faturamento de benefícios, ID de Empl, Código Ded e Quantidade.

Converta o máximo possível.

Saldos especiais de acumuladores.

Pode ser mapeado de Tess.

Saldos Fiscais e 1042 Saldos.

O mesmo que Saldo de ganhos, mas também precisará mapear o imposto do empregador.

A estratégia para validar as matrículas de benefícios será executar o Snap e, em seguida, executar relatórios para encontrar funcionários cujas inscrições tenham sido encerradas e também encontrar empregados erroneamente configurados no plano de benefícios incorretos.

Contrato Record e registro atual.

Precisa de todas as mudanças do ano atual mais inscrição aberta 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 auditoria, HIPPO e HICFA para todos os planos de benefícios. Incluir termina no centro de dados.

Terminar no ano atual ou no ano anterior entraria no PeopleSoft. Além disso, traga o ano atual e anterior para os funcionários ativos.

Não precisa da Data do Relatório HIPAA - não se converta. A carta HIPAA precisa ser enviada quando a COBRA terminar. Se a data do relatório HIPAA estiver no registro, isso impedirá que outra letra seja produzida?

Data de Início da Dedução, Data de Início da Cobertura.

A Data de Início da Dedução será padrão da Data de Início da Cobertura.

Identificador do provedor de saúde.

Dados Dependentes Cobertos - Relacionamento, endereço, país de nascimento, gênero.

Relacionamento também está disponível. Use o mesmo para todos os endereços. País de nascimento e local não utilizados. Como o gênero será padrão para desconhecido, se nenhum dado, esses funcionários não podem ser pagos ou processados ​​no Ben Admin.

Informações dependentes. deve estar no centro de dados. Será que o ano anterior entrará no Data Mall ou no PeopleSoft?

Os dados incorretos e os não exibidos para futuros contratos de DOF datados causam problemas. O DOF pode ir diretamente ao Orçamento de Ensino para adicioná-los para o Orçamento e aguardar bons dados antes de entrar no PeopleSoft?

Estado civil do cônjuge.

Use a mesma data do status matrimonial do funcionário de Dados Pessoais.

Data de Status do Estudante.

Data de falecimento dos dependentes.

Painel de comentários em Tess. Não se converta, mas use em frente.

Não converta o Beneficiário para os Planos de Benefícios de Vida, mas pode ser inserido manualmente depois de ir ao vivo. Há um campo no Tess atualmente não utilizado, mas pode ser atualizado no Tesseract antes da conversão.

A personalização pode determinar as regras STD ou o Ben Admin pode determinar os planos de benefícios.

2 planos em Tess precisarão ser combinados em um único plano.

A conversão depende de se o processamento de licenças estiver dentro do alcance da conversão.

TIAA ou TESS (problema de tempo)

Há um cálculo que precisaria ocorrer se a alimentação for direta da TIAA. A data de conversão determinará a origem.

Promessa Anual & amp; Deduções tomadas.

Ano anterior. & amp; Ano atual. No PeopleSoft.

Carregue em um plano 7X ou 7Y, mas traga os funcionários terminados no plano. Grupo PRU.

Inclua funcionários da COBRA, aposentados, etc. Existe um código no PeopleSoft.

Saldos e Pagamentos.

Os pagamentos de contas e os saldos estão em empréstimos e Recebíveis. As contas estão em Tess.

Convertimos todas as taxas e pagamentos do ano corrente ou ano anterior também? Isso depende se ou não passamos para L & amp; R.

O que queremos converter, se alguma coisa?

O link entre o Cônjuge Sobrevivente e o Empregado Falecido está em um campo de formulário livre.

Os benefícios precisam de informação de relatório. por 6 anos. Os funcionários falecidos podem ser convertidos no PeopleSoft ou no Data Mall? Em que data desenharemos a linha?

Não crie um evento COBRA para encerrar no PeopleSoft no momento da conversão.

Current & amp; Registros do ano anterior no PeopleSoft e em todos os outros no centro de dados.

Plano de Estratégia de Conversão de Dados PeopleSoft.

Para fazer perguntas e encontrar soluções.

Comentário de encerramento do autor.

Publicação destacada.

NOVO Veeam Agent for Microsoft Windows.

Backup e recuperação de servidores e estações de trabalho baseados em nuvem e física, bem como dispositivos de ponto final pertencentes a usuários remotos. Evite o tempo de inatividade e a perda de dados rápida e facilmente para as cargas de trabalho baseadas em nuvem física ou públicas baseadas no Windows!

Se você tiver um problema semelhante, faça uma pergunta relacionada.

Cursos sugeridos.

617 membros fizeram perguntas e receberam soluções personalizadas nos últimos 7 dias.

Junte-se à comunidade de 500 mil profissionais da tecnologia e faça suas perguntas.

Gostei da sua resposta?

Junte-se à nossa comunidade para obter mais soluções ou fazer perguntas.

Painel do painel de instrumentos.

Вложенные страницы.

Estratégia de conversão de dados.

Estratégia de conversão de dados.

Создатель Bryan Hutchinson, отредактировано фев 23, 2018.

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 em assuntos, por exemplo, elementos de dados definidos centralmente 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 possui ciclos de vida distintos que exigirão abordagens de conversão de dados igualmente 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 conduzidas por requisitos funcionais.

Um mapeamento de dados do legado para o KFS deve ser mantido ao longo da 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 rentável 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. Impulsionado e motivado por exigências funcionais indesejadas, a equipe buscará sensivelmente.

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 forma que ambos atendam às suas necessidades comerciais e facilitem 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 suportadas pelo time ID & amp; R com assistência da 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. Os usuários funcionais dependem da 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 de quem seu primeiro ponto de contato (nível 1) deve ser no caso de um suspeito de problema ou falha. Os scripts de conversão podem ser agendados para serem executados automaticamente após o carregamento bem-sucedido do Data Warehouse de Contabilidade (ADW ). Os scripts de conversão podem ser executados manualmente de forma 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 - Olhe para o Administrador de Dados da Universidade para facilitar o estabelecimento de um comitê de dados compartilhados semelhante ao PeopleSoft Shared Data Group. 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 2018.

Estratégia de conversão PeopleSoft - maio de 2018.

Создатель Dennis A Frederick, отредактировано мар 31, 2018.

Os valores do campo do gráfico legado são armazenados em várias tabelas no Peoplesoft. Quando o Plano de Contas da Kuali entrar em operação em julho de 2018, 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/2018 Kuali Financials entrar em operação. Devemos diferenciar os dados convertidos de forma secundária, para que possamos dizer conversão de dados inseridos, mas, de outra forma, deve ser idêntico. 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 de trabalho, "Distribuição de ganhos & quot; ligação. Pagamento Adicional (ADDITIONAL_PAY1).

Folha de pagamento para a América do Norte, Employee Pay Data EUA, Criar Pagamento Adicional, Pagamento Adicional. Página Dept Budget Earnings (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. "Contas de Despesas - Contabilidade de Não Compromisso" e "Contas de Responsabilidade - Contabilidade de Não Compromisso".

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 seqüências de contas de legacy de 17 caracteres armazenadas em tabelas que são produzidas a partir da folha de pagamento do 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)

Payroll North America & gt; Payroll Distribution & gt; Contabilidade de Compromisso USA & gt; Revisão Distribuição de 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 para um único salário. Online Results = Veja os resultados de cálculo do processo Online Check. Esta página aparece automaticamente cada vez que você envia um cheque online para o cálculo. Os valores de campo do gráfico armazenados na configuração do tipo de item devem ser convertidos em equivalentes Kuali. Instalação inicial (ITEM_TYPE_TBL) Configuração 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 Jrnl Set Chartfields. 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 periodicamente precisa ser reiniciada. Para obter atualizações para o mapeamento de conversão da tabela 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 2018 - Defina os requisitos detalhados da PeopleSoft para conversão. Comece o plano de conversão de produção.

Meados de final de maio de 2018 - Projeto detalhado para a conversão do PeopleSoft.

Junho 2018 - Codificação e testes unitários.

Julho-dezembro de 2018 - Testes funcionais, Testes com processamento a jusante.

Janeiro-julho de 2018 - Teste de ensaio de vestidos. Plano completo de conversão de produção. Execute a conversão de produção.