Date Scrambling on Infotype 41 Date Specifications

01 October 2019
Written by Adan Willemse

Adan worked as SAP HR and Time Management Consultant for more than 10 years before joining EPI-USE Labs in Australia as a Senior HCM Service Consultant in 2016. In 2018, Adan moved to Manchester, United Kingdom, and returned to Australia in 2021. In his time with EPI-USE Labs, Adan has gained extensive experience of helping clients to use Variance Monitor, Query Manager and Data Sync Manager on payroll migrations, divestments, report development, live Production system data redactions, and other interesting applications of the unique and powerful EPI-USE Labs' HCM Productivity Suite.

date-scrambling-blog-header-image

Every implementation of our software can throw up unique test data masking requirements. In this blog, one of our senior consultants Adan Willemse explains how Infotype 41 data had to be accurately masked in the test system, without devaluing the quality of the test data. In years gone by, this would have had us reaching for the ABAP exit functionality to code a solution, but with Data Secure 3, powerful masking rules can be built by anyone with knowledge of the data model, without the need for programming skills.

- Paul Hammersley, VP of ALM Portfolio at EPI-USE Labs

Infotype 41 challenges

SAP HCM customers are familiar with the Infotype 41 Date Specifications screen that stores many of an employee's key dates. We have blogged about the challenges of working with this infotype in the past from a reporting standpoint (see this blog about Fixing duplicate line reporting in SAP HCM).

sample-infotype-41-date-specifications-2Sample Infotype 41 Date Specifications

 

As we explain in that blog, Infotype 0041 permits storage of customer-specific dates. During configuration, each customer determines the date types that work best for them. In the example shown above, the associate has seven different date types stored as Date type 01, 04, 25, 50, C1, F3 and Z1, listed in alpha-numerical order. However, unlike traditional infotypes such as infotype 0002 Personal Data, in which each field only stores a singular value (for example, the first name field only stores first names in the P0002-VORNA field), the fields on this screen can store variable data. In Infotype 41, date type 50 could appear in the first box, the fourth box, the last, etc. depending on how many date types are on the screen.

This presented a challenge recently when I needed to mask the values of only certain sensitive dates stored on the Infotype 41 Date Specifications infotype. Because of the way that Infotype 41 Date Specifications are designed, I couldn’t be sure which field the date I needed to mask would be saved in (DAT01 - DAT12), only that it would be in one of the the “DAT**” fields that corresponds to the “DAR**” field that equals “50” in my case. In other words, the date field that corresponds to Date Type 50 for Service year entry.

To give you an idea of what this looks like behind the scenes, I’ve included below a screenshot as viewed from the SAP Data Browser (transaction code SE16N) showing the values from this infotype and how its corresponding DAT** field assignment varies from employee to employee. As you can see, Date Type 50 values are saved in DAT05 for some employees, DAT06 and DAT07 for others.

se16n-of-infotype-0041-2SE16N of Infotype 0041

 

Leveraging Data Secure to Scramble Infotype 41 Date Specifications

I used Data Secure 3 to solve the problem, using a standard date randomizing function, twelve filtered integrity maps and one rule added into my redaction policy.

Twelve Integrity Maps

I created twelve Integrity Maps, one for every Date Field on infotype 0041. (DAT01 through DAT12). Each Integrity Map had a Date Type Filter on the corresponding DAR** field, only allowing through records of Date Type 50.

twelve-integrity-maps-2
Twelve Integrity Maps

filter-for-date-type-50-on-each-date-type-field-2Filter for Date Type 50 on each Date Type Field

standard-integrity-key-mapping-2Standard Integrity Key Mapping

 

To ensure dates were always masked, I associated each integrity map with the default Random Date transformation function.

default-function-rnd_date-2Default Function RND_DATE

rule-editor-showing-masking-function-2Rule Editor showing all twelve IMAPs with the selected masking function

 

Testing

To be able to roll back data after I test my masking rule, I used Data Sync Object Sync to back up my set of employees to a file on the Application Server. I tested, using Object Masking for the ERP_PERSON Object, and specifying my policy, only activated the rule I was interested in. Because I selected Field Level Audit for in-place Object Masking, I could easily see the ‘before’ and ‘after’ values; the original date values, and again after they were randomized.

details-of-run-3Details of Run

 

Conclusion

Data Secure is a flexible product that is easy to use for ‘interesting’ cases such as these, where the exact field that must be masked varies from employee to employee. WIthin less than an hour, I could set up and test the masking of infotype 0041.

Find out more about Data Secure

 

 

Explore Popular Tags

GDPR Data Privacy Data Security Data Secure GDPR compliance Data Redaction data scrambling Data Redact General Data Protection Regulation POPI Act POPIA SAP Data Security SAP GDPR SAP data privacy and compliance Data Archiving Data Sync Manager Data privacy regulations Right to be forgotten Data privacy compliance GDPR readiness GDPR deadline Personal data SAP SAP security SAP systems GRC for SAP SAP data privacy and security Access Risk management Access risk controls Data Privacy suite Data minimisation Data security breaches Governance, Risk Management and Compliance (GRC) compliance COVID-19 Data privacy by design Risk monitoring SAP data copying and masking SAR Soterion Subject Access Request anonymised data Australian Privacy Act 1988 CCPA Cenoti Client Sync Data Protection Day Data masking EPI-USE Labs’ solutions European operations Federal Law GDPR fine Guest order ICO May 2018 Object Sync One-time customer Privacy by Design Reducing risk Right to Erasure Risk minimisation S/4HANA Migrations SAP S/4HANA SAP data SAP data privacy & security Secure scrambled production data for testing Test Data Management security breach Backlog privacy debt Black Friday Black Friday hangover Black Friday sales Breach Notification Brexit Budget Canada data privacy legislation Cenoti, connecting SAP with Splunk Cloud migrations Confidentiality Consent DSM DSM Readiness Assessment Data Diclose Data Portability Data Removal Data Replication Data Sync Manager (DSM) Data integrity Data privacy assessment Data processor versus controller Data retention rules Documentation Employee data Europe Friday 25 May 2018 GDPR-type legislation GRC GRC for SAP tools General Data Protection HCM HR ILM Information Commissioner’s Office Information transfer Infotype 41 JSOX New Zealand Privacy Act News Online shopping Penalties Personal Data Protection Law (PDPL) Phantom Proportional Data Protect personal employee data Removing data in SAP Right to Access Rise with SAP Risk management S4HANA SAP Cloud SAP Data Privacy Suite SAP RISE SAP SuccessFactors SAP access risk simulations SAP data encryption SIEM SOX Sarbanes-Oxley (SOX) legislation Saudi Arabia Security Security Information and Event Management Security for SAP. Live Sensitive HCM data South African data privacy legislation Splunk Splunk UBA Splunk’s Enterprise Security Success Factors Territorial Scope UK Government User Access Review Virtual conference What does the European GDPR mean for Australia? ebook masking rules quality of test data system copy uk sox
+ See More

Get Instant Updates


Leave a Comment: