Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
Alecsandra
Product and Topic Expert
Product and Topic Expert

Co-Authored by anja.jugel

Introduction


Distributing costs, expenses, revenues, or other numerical values from selected sources to target entities based on driver values is often executed using the structured allocation function of SAP Analytics Cloud. Allocations are not a standalone process but part of an integral planning workflow, where the input data that triggers the allocation process is often generated from prior planning activities, or the outcome data of the allocation process is subsequently utilized in planning activities. Implementing such a process framework in SAC uses a mix of functionality, with SAC Data Action at the core.

Given the interdependency of the structured allocation and data action functionality to enable an end-to-end process, we brought the allocations into the data actions in QRC2 2023 (for more details, see this video) to allow users a simplified and harmonized design time experience. Since then, we have encouraged users to create new allocations using the Data Actions instead of the Allocation Legacy Designer. Next, we plan to limit the usage of the Allocation Legacy Designer, and this blog post aims to give you visibility over the timelines and migration options. We are committed to making this transition as smooth as possible; hence, we offer a phased reduction approach of the Allocation Legacy Designer and migration tools to give you time to review and adapt to the data actions environment. In the first phase, you can manually migrate your structured allocations, while in the second, we will offer an automatic migration. 

Phase 1 (QRC1 2024)


With QRC1 2024, we start limiting the usage of the Allocation Legacy Designer and introduce a manual migration functionality to assist users in moving to Data Actions.

  • Disable the creation of new allocation processes and steps using the Allocation Legacy Designer but permit the editing of the existing allocation processes and steps.
  • Disable adding legacy allocation steps into data actions.
  • Provide manual migration of allocation processes and steps from the legacy tool to Data Actions.
  • Provide manual migration of legacy allocation steps in Data Actions.
  • Executing legacy allocations continues to be supported.


Manual Migration Overview

Users can manually migrate existing allocation processes or steps from the Allocation Legacy Designer. The migration process is very simple, consisting only of a few steps:

  1. Select the allocation process or step you wish to migrate to data actions and click “Migrate to Data Action”.
  2. Select the folder where the allocation process or step should be saved as a data action. Optionally select a new name and description for the saved data action.
  3. A message containing a navigation link to the newly created data action will be returned once the migration is completed.
  4. Optionally, review the newly created data action. If a multi-step allocation process was migrated, a corresponding data action step was created for each legacy allocation step within the data action.


The original allocation process or step will remain available in the Allocation legacy tool.

Manual Migration overview

 

Suppose legacy allocation steps were already added into data actions instead of using data actions' native functionality to define such a step. In that case, a migration option will also be available within the data action, as shown in the picture below.

Legacy allocation migration within Data Actions


The Allocation Legacy Designer allows the re-use of allocation steps within several allocation processes and data actions. The editing of a re-used allocation step will take effect on all processes and data actions referring to this step. During the manual migration, such relations are not considered. Each manual migration creates an independent data action representation of the migrated allocation step or process at the migration time. Nevertheless, you can easily preserve the dependencies by following these steps:

  1. Manually migrate each allocation step of interest that shall be re-used to a dedicated data action as described above. A data action with exactly one allocation step will be created for each such step.
  2. These data actions can be re-used as embedded in the data action steps to mirror the structure of your legacy allocation processes. For each allocation process, create a new data action and embed the required data action steps as nested data actions.


Editing a nested data action (created in the first step for a legacy allocation step) will now affect all data actions that embed this nested data action.

Phase 2 (QRC3 2024*)


With QRC3 2024, we will further restrict the Allocation Legacy Designer and offer an automatic migration mechanism.

  • Disable the editing of existing allocation processes and steps using the Allocation Legacy Designer.
  • Provide automatic migration of the allocation processes and step into data actions. Data action representations of all your current structured allocation processes and steps will be automatically created at the system update. You can directly use these data actions to adapt your planning processes.
  • In contrast to manual migration, automatic migration maintains all existing relations between allocation steps and processes. Re-used allocation steps will be migrated to nested data actions.
  • The original allocation process or step will remain available in the Allocation legacy tool. Executing legacy allocations continues to be supported.

We hope this information is useful and will help you prepare to move your structured allocations to data actions. Please do not hesitate to reach out for support with any questions or concerns during this transition period.

*All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations.
1 Comment