Изменение основных данных задним числом в HR

murmur

В кубе 0PA_C01 (Численность персонала и мероприятия) есть, например, такой признак 0AGE (Возраст), который рассчитывается в момент загрузки в трансформации (используется стандартный контент) на основании даты рождения. Предположим, что данные загружались в куб в течение года, а затем, выяснилось, что дата рождения была введена неверно по одному сотруднику и ее изменили на правильную. В этом случае, по идее, следует обновить основные данные сотрудника и перегрузить записи (предварительно удалив старые) по данному сотруднику в 0PA_C01. Не слишком хорошее решение. Аналогичные изменения могут произойти и в других признаках, 0AGE просто показан для примера. Вопрос - каким образом лучше всего разрешать подобные ситуации?

sergeyt

murmur написал:

В кубе 0PA_C01 (Численность персонала и мероприятия) есть, например, такой признак 0AGE (Возраст), который рассчитывается в момент загрузки в трансформации (используется стандартный контент) на основании даты рождения. Предположим, что данные загружались в куб в течение года, а затем, выяснилось, что дата рождения была введена неверно по одному сотруднику и ее изменили на правильную. В этом случае, по идее, следует обновить основные данные сотрудника и перегрузить записи (предварительно удалив старые) по данному сотруднику в 0PA_C01. Не слишком хорошее решение. Аналогичные изменения могут произойти и в других признаках, 0AGE просто показан для примера. Вопрос - каким образом лучше всего разрешать подобные ситуации?

Да и пол могут поменять

полное обновление с удалением предыдущих данных.

смотрим внимательно
Technical name: 0HR_PA_1
...
Delta Update
Delta update is not supported.

murmur

В описании контента еще упоминается решение на основе инфо-наборов, но что-то как-то не хочется на них отчетность строить.

И еще, как отслеживать изменения основных данных в HR? Ну опять-таки ту же дату рождения, например? То есть я могу, конечно, написать экстрактор, который будет выцеплять табельные номера сотрудников, по которым были изменения задним числом в персональных данных, передавать их в BW, либо же в самом BW при загрузке основных данных отлавливать изменения, которые потребуют перезагрузок, но может есть более строгий административный подход в самом HR-е, который запрещает менять основные данные без изменения полей DATEFROM и DATETO.

То, что дельта не поддерживается, это понятно, но это из другой оперы

sergeyt

murmur написал:

В описании контента еще упоминается решение на основе инфо-наборов, но что-то как-то не хочется на них отчетность строить.

И еще, как отслеживать изменения основных данных в HR? Ну опять-таки ту же дату рождения, например? То есть я могу, конечно, написать экстрактор, который будет выцеплять табельные номера сотрудников, по которым были изменения задним числом, передавать их в BW, либо же в самом BW при загрузке основных данных отлавливать изменения, которые потребуют перезагрузок, но может есть более строгий административный подход в самом HR-е, который запрещается менять основные данные без изменения полей DATEFROM и DATETO.

у нас нормально раз в неделю данные FULL перезагружаются, пока всех устраивает. Пакет отрабатывает за 5 мин.
Да и отчетность эта такая специфическая, ежедневная не очень и нужна.

sergeyt

murmur написал:

То, что дельта не поддерживается, это понятно, но это из другой оперы

В том и дело, что эти вещи связанные.

Smoky

А что если справочник объёмом более 1 000 000 записей и несколько его атрибутов могут меняться, какое решение лучше в данной ситуации?

sergeyt

Smoky написал(а):

А что если справочник объёмом более 1 000 000 записей и несколько его атрибутов могут меняться, какое решение лучше в данной ситуации?

Заставить-уговорить SAP написать фирменный дельта экстрактор.
Согласитесь, самопальные экстракторы будут так себе решением.
И еще, не возникает вопросов, почему SAP дельта-экстракторов для HR все еще не сделал?

Изменение основных данных задним числом в HR

Кто сейчас на конференции