With the introduction of the Fashion Management Solution (FMS), SAP has provided a HANA based option for the many Retail and Wholesale companies that rely on SAP’s Apparel & Footwear Solution (AFS) today. This new solution offers many advantages over its predecessor by combining key functionality from AFS and the IS Retail solution into a single platform. However, the migration from AFS to FMS can feel like a daunting and somewhat insurmountable proposition. There is a significant amount of data in AFS that needs to be migrated, plus it is likely to be heavily customized. Fortunately, SAP recognized this and has provided a data migration tool that not only can be configured to move the most common data elements, but also customized fields as well. We understand the challenges companies face when taking on these critical advancements and can make the process less intimidating as you embark on the activities of an AFS to FMS Migration (AFS2FMS). To get you started, we will provide an overview of the features and functions associated with SAP’s new Data Transport & Migration Tool (DTMT).
The architectural differences between AFS and FMS are significant, particularly in the area of the logistical applications. The main reason for this is the different architecture of AFS articles and its usage in the logistical processes. The variant diversity of AFS materials is based on the connection between the material master and its master grid (a matrix that holds the different characteristics of a product like colors, waist sizes, and lengths). Nearly all logistical processes in AFS where this kind of product is involved work exclusively on grid value level, which is also reflected in the underlying data structures. FMS however, is based on the architecture of SAP Retail where articles that differ only in certain characteristics are separate articles (variants) that are grouped together as a generic article. The figure below illustrates (at header/MARA level) what an AFS material and an FMS generic article look like, based on a simple 2 dimensional master grid, where SIZE2 is not utilized.
All logistical processes in FMS where generic articles are involved work on variant level, which is quite similar to SAP ERP since variants are autonomous articles. The different concepts of AFS materials and generic articles also impact all other logistical business objects like purchase orders and sales orders, conditions or purchasing info records, to name a few.
Due to the significant architectural differences between both sides, FMS cannot be reached via an upgrade of AFS. This means that AFS customers have to implement FMS (only possible on a HANA platform) from scratch, and migrate the application data from AFS to FMS.
To simplify this process, SAP provides the AFS2FMS migration solution to support customers’ data migration and transition to FMS. In addition, having an experienced service provider, such as /N SPRO, that understand the challenges and pitfalls of these type of projects, will enable customers to successfully transfer/migrate their data. This solution covers the complex transformation of the logistical business objects, as well as the data transition of the non-logistical ones, such as financial data. This fundamentally involves the data migration of an ERP system. The AFS2FMS solution is not an out-of-the box migration. It serves as a foundation for customer-specific migrations, where complex migration challenges caused by major architectural differences have been standardized into Migration Objects (MOs).
Due to the requirements of the AFS2FMS migration with regards to complexity and data volume, SAP developed a new ETL tool (Extract, Transform, and Load) called the Data Transport & Migration Tool (DTMT). DTMT is designed to transfer/migrate business object data between ABAP-based systems and is included in the licensing of FMS. The tool reuses the principles and methods of proven R/2 – R/3 migration, built on TDMS (Test Data Migration Server) foundations. The data migrated is read directly from the relevant source tables and written to a CSV file. From here, it is read by the corresponding migration and upload program on the target side, and transferred to the migration rule set. Once the conversion is complete, the data is written directly to the relevant tables in the target system, or if required, handed over to BAPIs that finally populate the data.
DTMT requires a design phase where the migration content, consisting of metadata definitions, table relations, structure and field mapping, and other elements, are defined. Based on this content, the final export and import programs are generated within the customer environment.
SAP does not provide standard configuration to migrate customizing data from AFS to FMS. Customers have to customize FMS from scratch within their implementation project. This is where experience can really mitigate the complexities of these migrations. With the right knowledge and background, DTMT can be configured to handle the migration of customizing tables, speeding up implementation. DTMT is an open tool, customers always have the option to extend the standard scope by developing additional migration objects within their project.
The delivered migration content can be customized to a certain degree. This allows customers to influence the way that data is migrated if multiple options exist. Customizing is performed in the target system on a scope (i.e. client) level, and is therefore valid across all migration objects (MOs). It has to be done before the first data import is performed, and it is split into the following sections:
- Domain Rules (DR) – Domain rules are central conversion rules that can be used in all MOs of a scope. They are always connected to a domain, and are used to convert fields assigned to the same domain, to ensure a consistent conversion across MOs within a scope. Domain rules are provided for most of the domains, referring to organizational entities like company codes, plants, and so on. They are also provided for other central fields like customer, vendor, or article numbers.
- Central Routines (CR) – These are similar to domain rules, but are not connected to a specific domain. They are used to implement coding that can be reused in several MOs.
- Fixed Values (FV) – Fixed values are centrally-defined variables whose values can be maintained from outside, via migration customizing.
- Translation Objects (TO) – Converting data via translation tables is the core process of any migration technology, where AFS configuration values are translated into FMS configuration values. Whenever there is a translation variant activated via migration customizing, it is necessary to maintain this translation table via customization. There is functionality embedded into DTMT that makes the customizing of translation objects more convenient.
In highly simplified terms, the actual data migration consists of the migration of the MOs in scope in a given sequence, taking the cross-MO dependencies into account.
The AFS2FMS can be split into the following blocks:
- MOs that have no predecessor object (Customer, Vendor, etc.)
- MOs that have predecessor objects (Article, Purchasing Info Records, Pricing Conditions, etc.)
- MOs where the data import is performed via BAPI (Purchase Orders, Sales Orders, Inventory)
The data migration volumes to FMS are large, depending on the number of grid value combinations translated. It would not be an exceptional case for 100 AFS materials to be converted into 10,000 articles in FMS, considering Color/SIZE1/SIZE2 permutations. Although this may sound a little scary, it is really fairly straightforward and the DTMT simplifies the migration process. To elaborate on the example, because each variant in FMS is a separate article, 100 AFS materials with 10 colors and 10 sizes combinations would result in the 10,000 FMS articles. After initial test migration of the sample set, the import log of MAT_GRID will provide table entries created in FMS. You can use this information to roughly calculate what this would mean for the migration of all your AFS materials, and also to understand why it is so important to clearly define the scope of the migration.
Hopefully, you are now less intimidated by the thought of undertaking a migration from your current AFS environment and are ready to explore the advantages that FMS can afford. Stay tuned for additional posts coming in the future to highlight other features and functions associated with SAP Fashion Management Solution (FMS). In the meantime, contact email@example.com for additional information and to suggest potential topics.