- SAP Managed Tags
Selective Data Transition with Time Slice
This post is regarding the Selective Data Transition with time slice.
What is Time Slice?
Applying a time slice allows you to selectively exclude data before a defined fiscal year from the scope of your digital blueprint.
Benefits
Source systems often contain a long history of data, which can lead to long migration runtimes and a high number of errors or inconsistencies in the post-processing phase (for example SFIN conversion). In many cases, this historical data is no longer necessary for operational, reporting, or auditing purposes.
The Lean Selective Data Transition SAP ECC to SAP S/4HANA scenario provided with SAP Business Transformation Center allows you to selectively exclude data related to specific organizational units (company codes) from your migration project. The time slice solution pattern offers the additional option of excluding data before a certain date, which reduces the system size even further.
This data reduction often means you can avoid additional memory extensions and reduce the risks associated with bringing along old and irrelevant data. It not only simplifies the migration process but also ensures a more relevant and valuable dataset at the end of the migration.
The time slice solution pattern uses a specific key date that determines which data is migrated and which is left behind. Transactional data created before the key date is not migrated, unless it is still in open status on the key date. All master data is migrated independently of the time slice, and transactional data created after the key date is also migrated.
The key date is always the start date of a fiscal year. The fiscal year can be different from the calendar year and is associated with the fiscal year variant.
To apply a time slice, you just need to select the fiscal year after which data should be included in the migration. The key date is the first day of the selected fiscal year, as derived from the fiscal year variant(s) of all the company codes that are set as In Scope for the digital blueprint. The time slice solution pattern is applied to all company codes in the scope of the digital blueprint.
After applying a time slice, the time slice-related filters are applied to all supported transformation objects in the modeling phase.
More specifically, the following data is migrated:
- All master data is migrated by default, even master data that's time-dependent and is dated before the key date of the time slice.
- Transactional data that is dated after the key date of the time slice.
- Transactional data that is in open status on the key date of the time slice. This could be, for example, transactional data from a Financial Accounting (FI) document with a posting date before the time slice key date, but with a clearing date that is after the time slice key date.
All transactional data related to standard transformation objects that come from SAP applications aren't within the scope of the time slice solution pattern. Time slice is supported for FI (Financial Accounting) and CO (Controlling) applications. Transactional data that doesn't come from FI and CO applications is migrated, independently of the time slice. The same is the case for all custom transformation objects.
Once a time slice has been defined in the scoping phase, the time slice filtering is applied to the transformation objects that are in scope in one of the following ways:
- No time slice is applied: The time slice is not applied to these transformation objects because they belong to an SAP component that is not supported by the time slice solution pattern. Currently, only standard transformation objects coming from FI (Financial Accounting) and CO (Controlling) components are supported.
- Filtering via a predecessor transformation object: These transformation objects are related to predecessors that already have a time slice applied. Therefore, a separate time slice filter is not needed.
- Filtering via a single table field: The time slice for these transformation objects is based on a single filter criterion. This can either be a specific date or the fiscal year. All data on or after the key date or fiscal year will be selected.
- Filtering using multiple filtering criteria: A time slice for these transformation objects is based on several filter groups, each of which consists of certain filtering criteria.
Things to remember: - Only one date can be considered for the time slice key date. If the fiscal year start date is not identical for all company codes that are in scope, then the earliest calendar date is considered as the time slice key date. This means that, for some company codes, there could be more data included in the migration.
For example, let's say you have some company codes in scope with a fiscal year start date of January 1st and other company codes with a fiscal year start date of April 1st. If you select 2022 as the fiscal year for the time slice, the key date will be 1.1.2022, as this is the earliest calendar date between the two fiscal year start dates. This means that, for the company code whose 2022 fiscal year starts on 1.4.2022, the data of the last 3 periods of the previous fiscal year (period 10, period 11 and period 12 of fiscal year 2021) will also be migrated.
A time slice needs to include a minimum of two fiscal years. If, for example, you're defining the time slice in mid-2024, the latest possible fiscal year you can select for the time slice is 2022.
For transactional data to be correctly included or excluded from the scope depending on its status, the period end closing needs to have been performed correctly for all fiscal years before the time slice start date.
Constraints
Before applying the time slice solution pattern, be aware of the following constraints:
- The fiscal year variant that is currently assigned to a company code (table <T001> and field <PERIV>) reflects the correct period definition for all fiscal years. If this is not the case, the key date for the time slice start cannot be determined correctly.
This is even more important when a change of the fiscal year has been applied in the past.
- Document reversals might not be possible after the migration if the original document wasn’t migrated. For example, it may not be possible to reverse an FI invoice if the corresponding logistics invoice in Material Management (MM) wasn't migrated.
- CO documents for expense postings before the time slice key date might not be migrated, as the migration of CO documents depends on the object type. Specifically, transactional data before the time slice key date that is related to object numbers starting with KS, KL, AO, and EO is not migrated.
This could mean that CO document line item postings before the time slice key date on a cost center are not migrated, and this can result in having an FI document with expense lines and an account assignment to a CO object (for example, a cost center), but no corresponding CO document.
- FI balances at the beginning of the time slice cannot be explained by their line items for accounts that are not open item managed. This is because FI documents are migrated with their open items, but the document may also include G/L accounts that are not open item managed. Balance sheet account line items with a posting date before the time slice key date may be migrated, while, on the other hand, the balances on the same G/L accounts before the time slice key date are not migrated.
For example, let's say the time slice key date is 01.01.2021. When you display the balance of a G/L account for the fiscal year 2019, the balance is zero. When you drill down to the line item display, however, there may be some line items present. The reason is that these G/L account line items are included in an FI document with open items.
- Complete document flows are not guaranteed. For example, the sales order of a document flow might not be migrated if it was created before the time slice key date and has a completed status. However, the related invoice and open item on the customer account are migrated because they are created within the time slice.
- When using standard reports to compare open items on customer, vendor, or G/L accounts, discrepancies may arise between the source and target systems if the report's key date is earlier than the time slice key date. This occurs because standard reports include items that were open on the report key date (i.e., posted on or before it and cleared after it). However, if an item was both posted and cleared before the time slice key date, it is not migrated when the time slice solution pattern is active. Consequently, this can cause differences between the source and target system reports.
For example, the time slice key date is 01.01.2022. An invoice on a customer account has a posting date of 13.08.2020 and a clearing date of 15.01.2021. When you report open items with a report key date of 01.01.2021, this item will be included in the report from the source system. In the target system, however, this item will not be available and consequently not included in the report. The reason is that this item was not migrated to the target system, as both its posting date and clearing date are before the time slice key date.
| User | Count |
|---|---|
| 4 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
