Integração do SAP SuccessFactors Employee Central com pagamento variável

Muitos dos registros no Employee Central têm data efetiva, ou seja, cada vez que uma transação é inserida, o sistema solicita que forneça uma data de início efetiva, que cria os registros históricos, presentes e futuros no Employee Central. A data efetiva da planilha controla a importação de informações datadas do Employee Central para linhas resumidas SOMENTE de pagamento variável.

• A data efetiva NÃO se aplica a registros do histórico do colaborador VRP, somente aos campos Nível do resumo (ou seja, Nível de entrada)
• TODOS os campos de nível de resumo devem usar a mesma data efetiva (ou seja, não pode chamar o salário a partir da data final do plano, mas o departamento a partir da data mais atual.)
• A data efetiva NÃO afeta as regras de elegibilidade do plano VRP. As regras de qualificação sempre serão relacionadas às datas no histórico do colaborador, pois os funcionários podem ser movidos durante o período do plano.
• Observe que nem todos os objetos do Employee Central têm data efetiva (detalhes do emprego, por exemplo). A data efetiva é ignorada para esses objetos do Employee Central.

Existe um cenário especial que existe para algumas empresas chamado modelo híbrido.

• Um modelo híbrido é onde alguns usuários são armazenados no Employee Central e outros fora do Employee Central, embora ambos estejam planejados em Pagamento variável. Um cenário híbrido pode aumentar consideravelmente a complexidade e, geralmente, não é preferido. Uma alternativa recomendada é ter um modelo para cada população separada.
• Os modelos híbridos usam a importação de dados baseada em arquivo e a integração de dados.
• Dois tipos de empregados:
  1. O mapeamento de dados do Employee Central ainda será usado para colaboradores do Employee Central.
  2. O mapeamento de dados do arquivo de dados do usuário (importKey) será usado para colaboradores com registros de histórico importados.
• Híbrido NÃO significa que você pode ter fontes de dados mistas para um único colaborador. NÃO é possível selecionar alguns dados no nível do campo do Employee Central e os dados restantes no nível do campo da importação de usuários para o mesmo usuário.
• Os planos híbridos ainda podem aplicar regras de elegibilidade não MDF a registros de histórico, portanto, você pode precisar de um arquivo de regras de qualificação para aplicar regras a esses usuários.
• O histórico do VRP de um colaborador deve ser exibido no Employee Central OU na importação do histórico, não ambos.
• Os colaboradores ainda DEVEM existir no SAP SuccessFactors (ou seja, devem ter registros de ID de usuário e de perfil do colaborador).

As configurações de publicação refletem como os componentes de pagamento não recorrente são mapeados e configurados em XML. A data efetiva é editável para que os administradores da empresa possam atualizar facilmente as datas de pagamento na IU.

Filtro de publicação de usuário: controla qual campo personalizado relatável pode ser usado como filtro ao publicar colaboradores selecionados. Você pode usar até cinco campos personalizados como critérios ao publicar dados no Employee Central.

• Permitir importação do histórico do colaborador: escolha Sim se alguns registros de colaboradores não estiverem no Employee Central, como um cenário híbrido.
• Executar cálculo de gratificação por regras de qualificação não EC: escolha Sim se usar o arquivo de qualificação para atribuir planos de gratificação aos colaboradores.
• Mesclar registros similares do Employee Central: escolha Sim se você quiser mesclar registros adjacentes que não afetam os dados do colaborador e os campos de qualificação que chegam a Pagamento variável.
• Ativar regra de elegibilidade global: a regra de elegibilidade global é usada para filtrar registros de usuários. Quando selecionados, dois campos adicionais serão exibidos, um para definir a regra e outro para definir a data efetiva da regra. Se este último for deixado em branco, o fim do programa de pagamento variável é considerado a data efetiva para a regra de elegibilidade. Um exemplo de caso para usar esta opção seria se o programa de pagamento variável do cliente contivesse uma regra global especificando somente para colaboradores ativos a partir de 1º de janeiro. Se uma regra de qualificação global for criada para o status igual a ativo e a data de efetivação estiver definida para 1º de janeiro, somente os colaboradores que atenderem a esses critérios serão selecionados para processamento de qualificação posterior. Outro exemplo é conceder bônus apenas a empregados que tiveram menos do que um determinado número de dias de férias não remuneradas.
• Configure várias regras por entidade do EC para o programa: escolha Sim se quiser criar regras de elegibilidade diferentes para entidades diferentes. Esta é uma solução que permite dividir regras complexas do Employee Central em regras menores, tornando-as mais gerenciáveis. Esta opção também tem um impacto na melhoria da performance do programa.
• Regra de qualificação para registros de histórico do colaborador: determina quais registros serão considerados para o cálculo de gratificação. Se existir uma regra de qualificação global, somente os registros que passaram nas regras globais serão considerados para o processamento do histórico do colaborador.

Os formulários de pagamento variável contêm muitos campos que pertencem a seções diferentes. Para integrar com êxito, você deve conhecer os objetos suportados do Employee Central em cada seção do formulário de pagamento variável. Uma coisa permanece constante, todos os campos usados em Compensação e Pagamento variável devem existir no Employee Central em tabelas acessíveis.

Estes são os campos que são exibidos na linha de resumo e os dados obtidos com base na data de efetivação do modelo. É importante observar que nem todos os objetos do Employee Central são datados. A data efetiva é ignorada para objetos do Employee Central sem data efetiva. Os objetos atualmente disponíveis suportados no mapeamento de campos de resumo são os seguintes:

• Informações do cargo
• Informações de compensação
• Componente de pagamento recorrente
• Componente de pagamento não recorrente
• Grupo de componentes de pagamento
• Informações pessoais
• Detalhes do emprego
• Relações de trabalho
• Informações pessoais
• Perfil do colaborador (elementos padrão no modelo de dados de sucessão)
• Objetos personalizados MDF

Diretrizes no uso do mapeamento de campo EC no nível do resumo:

• Associações ou valores preenchidos por regras de negócio devem ser evitados.
• O tipo de campo deve ser correspondente. Os campos devem ser mapeados para o tipo de elemento correto. Um campo "string" não deve ser mapeado para um campo "número" ou vice-versa.
• Carregamento sem dupla, alguns campos via arquivo simples e outros via integração, a menos que use modelos híbridos.

Estes são os campos relacionados a atribuições de colaborador que podem ser usados em metas de negócios em cascata. Uma distinção importante entre planos integrados do Employee Central e não do Employee Central é a relevância do histórico do colaborador para atribuir planos de gratificação. Para planos não integrados ao Employee Central, as informações no histórico do empregado são usadas para determinar como os empregados são atribuídos a planos de incentivos, o que não é o caso para planos integrados ao Employee Central. O plano de pagamento variável integrado ao Employee Central usa regras de negócios para atribuir colaboradores a planos de gratificação. Para facilitar a validação e a solução de problemas, a abordagem recomendada é incluir o campo usado nas regras comerciais para o mapeamento do histórico do colaborador.

Os objetos do Employee Central suportados no mapeamento de campos de histórico incluem:

• Informações do cargo
• Informações de compensação
• Componente de pagamento recorrente
• Componente de pagamento não recorrente
• Grupo de componentes de pagamento
• Informações pessoais
• Detalhes do emprego
• Informações pessoais
• Perfil do colaborador (elementos padrão no modelo de dados de sucessão)

A configuração do elemento de experiência usado para o histórico do colaborador permanece a mesma, com exceção de um novo campo, recordType. O elemento de experiência DEVE ter este campo para planos integrados ao Employee Central. Após o mapeamento de campos, as regras de negócios devem ser criadas para executar o processo de histórico do colaborador. O mapeamento de campos do histórico do colaborador não extrai dados do Employee Central a menos que uma regra de negócios seja criada para filtrar os colaboradores elegíveis. Isso é discutido mais abaixo na seção Regras comerciais.

Depois de analisar o mapeamento do histórico do colaborador, é importante saber como o histórico é gerado:

1. As regras de elegibilidade global e histórica determinam qual registro é extraído.
2. Uma linha diferente será chamada para cada alteração de dados que um empregado teve ao longo do ano.
3. Todas as linhas serão comparadas e linhas idênticas serão consolidadas.
4. A base é calculada com base em como a meta de bônus e as porcentagens são mapeadas (discutidas mais adiante na próxima seção).

Inicie o processador do histórico do colaborador para obter dados do Employee Central. Ao chamar dados inicialmente, deixe as três opções em branco. Considere as seguintes descrições para execuções subsequentes:

• Importar somente registros alterados: selecionar esta opção importará registros somente para colaboradores cujas informações de atribuição foram alteradas no Employee Central. Essa abordagem só é recomendada se você tiver um pequeno conjunto de registros alterados a serem atualizados em Pagamento variável. Se esta opção não for selecionada, o Pagamento variável importará todos os registros qualificados do Employee Central.
• Não atualizar formulários preenchidos: selecionar esta opção não atualizará os registros do histórico do colaborador que já estão presentes em um formulário preenchido. Se um empregado estiver em um formulário preenchido, seus registros não serão atualizados.
• Executar cálculo de gratificação e atualizar formulários iniciados: selecionar esta opção acionará as tarefas de cálculo de gratificação e atualização em massa após a importação dos registros. Os dados de bónus para colaboradores que tenham registos alterados serão atualizados em quaisquer formulários que já tenham sido lançados.

A base para planos integrados ao Employee Central é mapeada separadamente do histórico do colaborador. Atualmente, os seguintes objetos do Employee Central são suportados para mapeamento de base:

• Informações do cargo
• Informações de compensação
• Grupo de componentes de pagamento

Para programas integrados, a base pode ser derivada de uma de várias formas:

1. Alvo do bônus e "%" derivados das Informações do cargo – melhor para programas específicos da pessoa ou para programas baseados em ganhos (por exemplo, funcionários não isentos ou por hora) OU programas em que há necessidade de base calculada externamente.
   1. Os ganhos/bases podem ser carregados no Employee Central
   2. Lucros/base podem vir de uma tabela carregada
   3. Porcentagem pode ser um campo personalizado em jobInfo ou um campo personalizado na faixa de pagamento
2. Alvo do bônus derivado do grupo de componentes de pagamento e "%" das Informações do cargo – melhor quando o ponto de partida do cálculo de base é um valor estático, como uma taxa de pagamento ou combinação de taxas que são multiplicadas por uma porcentagem alvo.
   1. O grupo de componentes de pagamento é a "soma"
   2. A porcentagem de informações do cargo fornece a porcentagem
3. Alvo do bônus e "%" derivados do grupo de componentes de pagamento – melhor quando o grupo de componentes de pagamento é a totalidade da base e a porcentagem de destino incluída. Usado quando as porcentagens alvo são armazenadas como componentes de pagamento.

   O grupo de componentes de pagamento é a "soma" incluindo a porcentagem.

O sistema permite a utilização das três opções. Se mais de uma fonte for selecionada, a prioridade para cada usuário será baseada na ordem precedente listada.

Por padrão, o pagamento variável calcula um valor de destino de bônus (base) com base nas alterações de cargo. No entanto, nem todas as empresas usam o mesmo cálculo da forma exata granular pretendida pelo pagamento variável, em que as alterações de cargo e as datas de efetivação orientam o processo.

Uma opção em Pagamento variável suporta o uso do cálculo pontual. Por exemplo, use sempre o salário como 31/12, mesmo que a remuneração tenha mudado ao longo do ano. Esta configuração pode ser aplicada a salário/ganhos e/ou porcentagem de destino.

O Employee Central pode aplicar um conjunto robusto de regras de elegibilidade. Assim como a compensação, o pagamento variável não precisa da condição THEN nas regras. Há várias regras de elegibilidade envolvidas nos planos de pagamento variável integrados ao Employee Central e maneiras diferentes de como elas são usadas:

• Regras de qualificação global é uma regra opcional que pode ser aplicada para filtrar colaboradores antes de serem processados para o histórico do colaborador. Esta regra requer uma data efetiva.

  Exemplo: uma empresa tem 10.000 registros de usuário no sistema, dos quais 1.000 estão inativos. A regra de qualificação global pode ser usada para filtrar somente colaboradores ativos a partir de 31/12/2019. Considere que a data efetiva não é inserida como um parâmetro na regra comercial, mas aplicada nas configurações do plano.

• As regras do histórico do colaborador filtram os registos para o cálculo do bónus.

  Continuando com o exemplo anterior: dos 9.000 colaboradores ativos que são filtrados da elegibilidade global, apenas 7.500 são elegíveis para o cálculo de bônus.

• A qualificação do plano de gratificação atribui os colaboradores qualificados a planos de gratificação específicos.

  Dos 7, 500 colaboradores elegíveis processados para o histórico do colaborador, 5.000 são atribuídos ao plano de gratificação gerador de receita, enquanto o restante é atribuído ao plano de gratificação que permite receita.

• Gerenciar elegibilidade do formulário é o mesmo que em Compensação, quem você gostaria de ver no formulário?

  Exemplo – até mesmo colaboradores sem um plano de gratificação podem ser incluídos no formulário.

Para publicar os resultados do planejamento de gratificação no Employee Central, o <comp-ect-output-component> é usado para definir o mapeamento entre o campo de origem em Pagamento variável e o campo de destino no Employee Central. Atualmente, a publicação está limitada à entidade payComponentNonRecurring do Employee Central. Os pagamentos de gratificação podem ser publicados por colaborador, selecionados ou todas as planilhas.

componentType: especifica o tipo de componente de pagamento. Em Pagamento variável, só usamos payComponentNonRecurring.

componentCode: especifica o código do componente de pagamento.

eventReason: especifica o motivo do pagamento. OPCIONAL para componentes de pagamento não recorrentes. O motivo do evento pode ser alterado na IU. Quando o motivo do evento é configurado no nível do funcionário (por exemplo, usando uma tabela de pesquisa), ele tem precedência sobre o valor padrão.

effectiveDate: especifica a data de pagamento para componentes de pagamento não recorrentes. Se uma data for especificada para o campo hris-, essa data terá precedência. As datas podem ser editadas na IU.

comp-hris-field-map: especifica os nomes do campo em Compensation (comp-field-id) e Employee Central (hris-field-id).

1234567891011121314
<comp-ect-output-component componentType="payComponentNonRecurring" componentCode="MIP_BONUS" eventReason="MIP_AWARD" effectiveDate="2021-04-01">
    <comp-hris-field-map>
    <comp-field-id><![CDATA[localCurrencyCode]]></comp-field-id>
    <hris-field-id><![CDATA[currency-code]]></hris-field-id>
    </comp-hris-field-map>
    <comp-hris-field-map>
    <comp-field-id><![CDATA[Final_MIP_Payout_Amt]]></comp-field-id>
    <hris-field-id><![CDATA[value]]></hris-field-id>
    </comp-hris-field-map>
    <comp-hris-field-map>
    <comp-field-id><![CDATA[customPayoutDate]]></comp-field-id>
    <hris-field-id><![CDATA[pay-date]]></hris-field-id>
    </comp-hris-field-map>
    </comp-ect-output-component>

• Vários componentes de pagamento não recorrentes podem ser publicados.
  • O novo componente de pagamento é criado do zero com os valores de objeto de base preenchidos.
  • Os valores de campo são definidos com base no comp-hris-field-map.
• Os mesmos componentes podem ser publicados várias vezes.
  • A primeira publicação cria um novo componente de pagamento.
  • A publicação subsequente atualiza os componentes de pagamento publicados a partir do mesmo modelo e cria novos.

1. Navegue para Página inicial de compensação→Selecione o modelo de compensação→Ciclo de compensação completo→Publicar dados. Você pode selecionar a população que pode ser publicada de volta no Employee Central. A publicação em vários lotes melhora o desempenho geral do processo de publicação.
   • Use Publicar no Employee Central para publicar em massa registros de todos os formulários concluídos. O tempo de processamento depende do número de registros.
   • Utilizar Publicar folhas de trabalho selecionadas para registros de processo em background para selecionar folhas de trabalho concluídas.
   • Use Publicar colaboradores selecionados em registros de processo em lote para selecionar colaboradores de formulários concluídos. Os empregados podem ser inseridos um de cada vez ou podem ser importados utilizando um modelo CSV.
2. Selecione Enviar quando estiver pronto para publicar.
3. Monitorar tarefas de compensação pode ser usado para acompanhar o status da sua solicitação.

Uma ferramenta de publicação de relatório do Employee Central pode fornecer um log detalhado de uma tarefa de publicação. A ferramenta exige que a permissão de administrador Exibir relatório de publicação do Employee Central esteja ativada. Um relatório de planilha eletrônica pode ser gerado com base em critérios definidos pelo usuário para identificar irregularidades durante o processo de publicação.

• Remova (ou modifique) os campos personalizados utilizando o tag importKey. NÃO há suporte para que a configuração use importKey na integração Employee Central-Compensation, portanto, você deve remover TODAS as referências para importar a Key em seu XML para iniciar as planilhas. Isso inclui importKeys definidas nas seções Orçamentos e Fonte de Classificação do XML.
• Para integrar dados do histórico do colaborador, como varPayProgramName, startDate, endDate, base, registro Type não são mapeados no Histórico do colaborador. Importar metas e pesos de negócios.
• As regras de negócios para pagamento variável usam somente varpayEligibility como tipo de regra.
• Quaisquer atualizações de dados no Employee Central não são refletidas automaticamente até a próxima vez que o processo de importação for executado. Lembre-se de que a Data efetiva da planilha só se aplica a campos de Nível do resumo e não a campos de Histórico do colaborador. Um trabalho de importação chamado Processador de histórico da Employee Central pode ser definido no agendamento recorrente no provisionamento.
• Para todos os componentes de pagamento não recorrentes, supõe-se que o componente de pagamento seja um componente de pagamento independente que não está conectado aos dados de compensação do Employee Central.
• Os campos de valor monetário e valor não podem ser publicados em um campo longo personalizado no Employee Central.