Table of Contents. Master Data Management for Apparel and Footwear Industry: SAP MDM and AFS Integration Design

Transcription

1 Master Data Management for Apparel and Footwear Industry: SAP MDM and AFS Integration Design Applies to: SAP NetWeaver Master Data Management (MDM) 7.1 SP04+, SAP NetWeaver Enterprise Portal (EP) 7.0 SP19+, SAP for Apparel and Footwear Industry (ECC 6.0) For more information, visit the Master Data Management homepage. Summary The purpose of this article is to introduce the nuances of integration of SAP MDM with SAP for Apparel and Footwear (AFS) industry solution. The target audience for this document includes NetWeaver Solution Architects, Project Managers, Implementation team members and customer project team members who want to gain a pre-design and implementation insight into the options available with their pros and cons to help them in their decision making and reducing the time for design and implementation Author: Sudhendu Pandey Company: SAP America Created on: 31 August 2010 Author Bio Sudhendu works with SAP America as a senior consultant and NetWeaver solution architect in the Enterprise Information Management practice. He has worked on multiple end to end implementations across several industries and in multiple countries. He believes in sharing knowledge that helps to improve the experience of the implementation team as well as the end customer for SAP Solutions SAP AG 1

2 Table of Contents Document Purpose... 3 What is Required to Understand the SAP for AFS Solution: The Functional Piece... 3 The Example Material and SKU... 3 Detour: SAP for Retail Industry... 5 The Fun Starts Here: Master Data Model Design Options... 5 Design Option 1: Material and SKUs (Grid header and details) in the Same Main Table without any Repeating Sub-Structures... 6 Design Option 2: Material and Grid Header in the Main Table with Associated Grid Details in a Qualified Table 7 Design Option 3: Material and Grid Header in the Main Table with Associated Grid Details in a Multi- Valued Tuple... 8 Design Option 4: Material and Grid Header in the Main Table with Associated Grid Details as Attributes of a Taxonomy... 9 Design Option 5: Material and Grid Header in One Main Table with Associated Grids in Another Main Table 9 Design Option 6: Material in One Main Table with Master Grid Header in its Own Main Table with Grid Details Data in a Multi-Valued Tuple Integration Considerations IDoc types Syndication Sequence Vs 3 Dimensional Grid Data and Differences in Syndication Related Content Copyright SAP AG 2

3 Document Purpose The purpose of this article is to introduce the nuances of integration of SAP MDM with SAP for Apparel and Footwear (AFS) industry solution. The inputs for this package are derived from practical experience gained in implementation projects where similar integration was attempted. The contents should be considered as guidelines only and not final recommendations for similar projects. It is the intention of this document to provide options for consideration when defining the solution for a similar integration and it is the final judgment of the solution architect that should decide the best option in their particular situation. The ultimate aim of this integration was to provide a central master data management environment for end users to create material master and related SKU(s) (Stock Keeping Units, as explained later). Only the parts relevant to the title of this document have been presented here. The target audience for this document includes NetWeaver Solution Architects, Project Managers, Implementation team members and Customer project team members who want to gain a pre-design and implementation insight into the options available with their pros and cons to help them in their decision making and reducing the time for design and implementation. This package also helps to point out the important questions that need to be raised during the design phase at appropriate stages to help in defining the best design of a new system. The contents in this document assume basic understanding of SAP MDM data modeling, a basic solution and process level thought process and design concepts in information integration. What is Required to Understand the SAP for AFS Solution: The Functional Piece SAP for Apparel and Footwear Industry solution like other industry specific solutions from SAP includes functionalities that are characteristic of the garment manufacturing and wholesale distribution industry requirements. It is an adapted version of the basic ERP solution (ECC) that would otherwise require greater customization (Industry and Customer specific development) to address the needs of this particular industry. In a plain ERP system, the commonly understood Material master definition would be found and used to carry out ERP related activities like Material Management, Production Planning, Inventory Management, Warehouse Management etc. with slight variations depending on the type of material being managed - like a raw material will be managed differently than a finished product. The AFS solution introduces another dimension of design into the basic material master by extending the concepts of ERP to material as well as SKU (Stock Keeping Units - products that are sold to customers). Hence material management, planning, forecasting and inventory management can be performed at the material as well as the SKU level depending on the configuration and the requirements. The above discussion leads to the inference that the relationship between a material and its SKUs is the most important aspect of this design. This is the fundamental building block of the design in MDM which in turn helps to establish the relationship in the ERP system correctly. One material (which is like a template for a SKU) can have multiple SKUs related to it. The Example Material and SKU To create a reference for further discussion, consider one of the most important products of the garment manufacturing industry - a shirt (gender here does not matter). A trouser can also be a good choice as an example. A shirt can have several properties (or attributes) like Size, Sleeve Length (for sleeved shirts), and Color etc. These are called dimensions or characteristics in AFS lingo. Each such attribute (characteristic can have several possible values - like Size can be Regular, Large, Extra Large etc., Sleeve length can be - Long sleeve or Short Sleeve etc. To structure this information - we call the attributes as characteristics or dimensions and specific values for attributes (regular, large extra large etc.) as characteristic or dimension values. It is the combination of a set of characteristic values that help to define SKUs or a Master Grid (Set of SKUs of the same type) in AFS. In the context of the example above, a Large Full sleeve Yellow shirt would form 2010 SAP AG 3

4 one SKU which is sellable to customers. When considering ERP processes at the SKU level, like planning, material management, inventory management etc. we are trying to determine answers to questions like: - What should be stock for a particular SKU - What is the optimal number of the Large Long sleeve Yellow shirts that should be in stock to avoid stock out situations? Of course the answer depends on other factors like demand planning, forecasting based on historical sales etc. but it is important to define the SKU correctly from the start so that the entire operations and supply chain management flow of information is consistent - What should be the quantity of procurement of raw materials that are used to manufacture similar SKUs? This question again depends on inputs from other processes like demand planning and forecasting but is dependent on the quality and consistency of master data that is used to execute these processes At this juncture it is noteworthy that accurate and consistent definition of material and SKU master data creation and maintenance based on a well defined governance process is a pre-requisite to transaction system accuracy and reporting efficiency. Starting from the sourcing and planning teams that define these SKUs to the manufacturing and sales teams that use these definitions in their processes, if everyone understands the conventions used in defining materials and SKUs they are more likely to have a predictable and certain process Vs a situation where user errors for example would allow ambiguity in the definition and identification of SKUs in particular and affect the manufacturing, inventory and sales processes in turn. Since SKUs are "possible" combinations of characteristic values for the selected characteristics, these combinations can be a large number depending on how the characteristics and their values have been defined in the system. For a two dimensional design (with two characteristics used to define the SKU) the number of combinations would be m x n where m = number of characteristic values for characteristic 1 and n = number of characteristic values for characteristic 2. For m = 10 and n = 20, the number of SKUs that can be defined is 10 x 20 = 200. Similarly, for a 3 dimensional design, the possibilities increase as now we can have m x n x p total combinations tending to 1000s in magnitude. It is not uncommon to discover data sets running into millions of records for a reasonable sized business. This leads to the following important questions during design of a new system: 1. What is the number of dimension that is being planned for use? It is important to know this early on as this has impact on the design 2. What are the number or characteristics and average number of characteristic values per characteristic that are planned for use? This will in turn help to project the size of the record we can expect to have in the new system - a pointer to the sizing and performance considerations besides the regular ones 3. What would the most complex SKUs look like (the shirt has been taken as an example here as it represents one of the most complex Grids in this industry) in terms of number of SKUs and the possible characteristic combinations. We may not end up designing the new system for this maximum but it is a good indicator of the stress the system should be expected to support. Interestingly, the concept of material and SKU is similar in case of Retail industry. In fact the concept and relationship between a material (as a parent or template) and its corresponding SKUs (as children or instances of the template) is shared by the CPG (consumer Products) or the FMCG (Fast Moving Consumer Goods) industry also. From a master data perspective, the AFS Master Grid can be created and exist without reference to a material, which implies: 1. A material for which the grid will eventually be used need not be pre-defined when defining the grid itself. 2. The linkage to a grid (set of SKUs of the same type) of a material is what makes the material "AFS specific". Without this linkage, the material is like a regular material. 3. Due to the loose coupling between the grid and material, it becomes possible to reuse a grid definition multiple times across several materials. The grid number is the link between the material and its SKUs and the AFS system allows reuse of grid numbers. The above leads to some important questions during design: 2010 SAP AG 4

5 1. Does the business for which implementation is planned intend to use a grid only once or reuse the same grid multiple times? This also means that a one to one relationship between the material and the grid (a grid is not reused) would lead to a larger data set consequently requiring a larger hardware footprint to support it. Another implication is the design of the new system where a one to one relationship based design may not be suitable for a one (grid) to many materials based design. 2. At what level does business plan to execute "MRP runs"(to determine the manufacturing resources required to produce the final product) - material level or the SKU level? While a SKU level run might be more accurate and precise, it has implications on the design as there could be cases where material and SKU specific planning values are to be maintained and these might be tightly coupled with the material/ SKU and exists along with it. It should be noted that the Master grid is only one of the three types of Grids available in the AFS system. The other two being the sales and purchasing grids that are related to sales and purchasing activities. These two grids however are derived from the master grid in most cases. More details can be found in the AFS documentation as referred towards the end of this document. Technically, the Master grid has two parts The Grid Header - Information which is common across all the Characteristic value combinations (SKUs) like the Grid number, its description, validity dates, Characteristic names that are specific to all the SKUs for the grid like size, inseam etc. The Grid Details - Information which is a level below the header logically and represents unique characteristic "value" combinations themselves (the SKUs) like Regular, Large, Medium Sizes for the same type of inseam for all SKUs. These two parts are defined as two related tables at the database level in the AFS solution. Although the grid can exist independent of a material, but it only becomes meaningful when linked to a material as transactions are executed over a material and its related SKUs in case of a gridded material. The independent existence allows reuse of the grid definition across several materials which are similar. Detour: SAP for Retail Industry Without exploring it in detail, it is important to mention a similar solution - the SAP for retail industry solution where the concept of a material and SKU is more tightly defined. In the retail solution, the concept of "master" and "variant" is used to relate the two. A master being the parent or the template material and the variants being the children or specific attribute combinations attached to a parent. In most cases the material or the master by itself is not usable in business processes unless variants are also defined based on it. In this case, unlike the AFS solution (where the grid can and does exist without the reference or existence of a material) the master and the variants (SKUs) exist together. This also implies that the variants may not be reusable across several masters due to the tight coupling. The Fun Starts Here: Master Data Model Design Options This section explores and explains in detail the various data modeling options that can be considered while defining the Material SKU relationship within SAP MDM. Each design option will be presented along with its impact on integration and hence enables choices for implementation teams looking to design similar system. Though the discussion around design of a data model is based on the fundamental concepts of Normalized schema (Déjà Vu - Star, Snow Flake etc.),there might be concepts like qualified tables and tuples that might be unique to the SAP Master Data Management (MDM) product. To ensure basic understanding of these concepts, here are some definitions (not the ones found in documentation): Qualified table - it is an entire sub table within another (larger) table to create one-to-many relationships in a database. The presentation of this structure is such that the user is able to see the entire set of linked records in this table while remaining in the primary table itself. Examples of its use include - 1 Material to several plants, 1 customer to several contacts etc SAP AG 5

6 Tuple - a single or a multi-valued sub table like (because it is more of a logical grouping of fields and less of a physical table) structure that allows deeply nested relationships in a database. This also allows the user access to the entire set of linked records without the need to browse multiple tables to determine the complete information. They differ from qualified tables in that they can be defined as single or multivalued and can allow tuples within tuples. It is possible in some cases to use either qualified table or tuples interchangeably. Examples of its use include Phone, FAX and substructures within a Communication details substructure within a Business Partner Primary table. Each of the substructures for Phone, FAX and contain several fields within them to completely represent these pieces of information. Design Option 1: Material and SKUs (Grid header and details) in the Same Main Table without any Repeating Sub-Structures This type of design is encountered mostly in legacy systems with so called flat or de-normalized data models where every SKU is represented as a complete record in the primary table that contains the material itself. A consequence of this design approach is that every time a new SKU is created, it has a copy of all the field values that it borrows from the material and then adds its versions of field values that characterize it. For e.g. the shirt SKUs introduced earlier will have one record each for a different sized shirt for the same parent material. In the context of a master grid, the grid header and the details both are present within the same table in this design. Although simple to understand and realize, this type of design has the following impact: 1. Large redundancy in data as the same value is repeated across several SKUs which might differ from each other by just one attribute value. On the technical side, this results in a large storage and memory footprint and an occasional overhead on performance. 2. Large primary table with hundreds of fields typically to ensure all the records contain all the fields with their values to allow maintenance of individual field values per SKU 3. Alternatively, this design also allows creation of user interface where material and its SKUs can be represented at the same level without the need for special linkage as will be explained in the next few options 4. This design also allows mass maintenance of SKU level data using MDM clients. This type of maintenance can either be within the same material and its SKUs or even SKUs across multiple materials in case the change is generic to be applicable to all such SKUs 5. This design requires special considerations when support for Material Vs SKU field value override scenario (where the SKU level value of a field also present at the material level needs to be overridden to make it different from that at the material level) is in scope. The following diagram represents this design: Materials [Main table] Material No. Description.. Material Grid No. Grid Description Characteristic Name 1 Characteristic Name 2 Characteristic Name 3 Characteristic Value 1 Characteristic Value 2 Characteristic Value SAP AG 6

7 Design Option 2: Material and Grid Header in the Main Table with Associated Grid Details in a Qualified Table Characteristic of an MDM repository (as the qualified table is a unique substructure available in MDM), this represents a normalized data model where there is only one instance of a field value between a material and its SKUs. A qualified table in this case can be visualized as an embedded multi-valued structure within the main table that contains the material record. The qualified table in this case contains the SKU specific fields and their values (characteristic values) as child records to the main table material record. In this design, the common parts of the "Grid" (called the grid header information like Grid Number, description, characteristic names (not values) etc.) are maintained at the material level. In the context of a master grid, the grid header is in the same table as the material data and the grid details are present in the qualified table. This design has the following impact considerations: 1. Minimal redundancy of data as the material level field values are created and maintained only once at the main table level and inherit (during syndication) down to the SKUs. This design has a much lower memory and storage foot print - to the extent of 50% of the single main table only design option (1 above) 2. The end user is able to search and observe all the SKUs of a material while remaining within the material record itself in a single view. This reduces the need to browse several tables to understand the definition of the SKU with respect to the material. 3. Although a qualified table allows reduced redundancy and dual level data maintenance (material and SKU levels) it is challenging to support any further levels as a qualified table does not allow substructures within it. Hence this type of design is good only for those scenarios where a two level relationship is satisfactory. In other cases like the need to maintain SKU level plant information similar to maintaining the same at the material level (where plant data is another substructure within the material main table like the SKU qualified table) 4. Another consideration before adopting this design is the impact of large number of SKUs per material. In a garment manufacturing industry for e.g. one shirt or trouser may have hundreds or even thousands of SKUs linked to it and there might be several hundreds of such materials. The total number of possible SKUs (Characteristic value combinations) should be considered. 5. On the other side, this design allows mass maintenance of SKUs for a particular material where either multiple SKUs for a material or a particular SKU type across several similar materials might need to be changed simultaneously. In other designs, this functionality might have to be developed specifically. 6. In case of this approach, it is rarely possible to reuse SKU definitions across several materials to avoid recreating them again unlike the AFS grid which can be reused. The following diagram represents this design: Materials [Main Table] Material No. Description. Material Grid No. Grid Description Characteristic Name 1 Characteristic Name 2 Characteristic Name 3 Grid Details [Qualified Table] Characteristic Value 1a, Characteristic Value 2a, Characteristic Value 3a Characteristic Value 1b, Characteristic Value 2b, Characteristic Value 3b 2010 SAP AG 7

8 Design Option 3: Material and Grid Header in the Main Table with Associated Grid Details in a Multi- Valued Tuple Another design characteristic of an MDM repository and similar in concept to the qualified table design is the one using tuples as substructures for SKU level data. This also represents a normalized model where the material information does not repeat itself for every SKU created and is inherited. In this design also, the Grid header is maintained only once at the material level like the qualified table design. In the context of a master grid, the grid header is in the same table as the material and the grid details are modeled as the tuple within the material main table. Since it s possible to define deeply nested structures using tuples within tuples, this design increases the possible scenarios that can be realized with the following impact considerations: 1. Minimal redundancy of data due to normalization as in case of qualified table based design. Memory footprint in this case might be slightly higher (due to the way tuples are defined internally) than the qualified table. 2. The end user is able to visualize the material with its SKUs from a single point of access. In fact, tuples within a repository cannot be accessed like sub tables and their data cannot be maintained independent of the material. 3. With the use of tuples within the SKU level tuple, it is possible to realize scenarios like maintaining sub levels below the SKU level like plant data per SKU etc. A central tuple definition for plant data can be shared by the material as well as the SKU and override scenarios supported. Careful consideration needs to be given to the possibilities of syndicating these deeply nested schemas to other systems which may not have been defined similarly. 4. Like the qualified table design, this also does not allow reuse of SKU definitions beyond one material and in case similar materials are to be maintained, data needs to be recreated again. 5. In what seems like a temporary limitation (as long as it is not enabled in MDM), this option does not allow mass maintenance of SKU level information using the MDM clients and special development needs to be done to enable this functionality in case required. This can be an important consideration while selecting a design option. This is true as of MDM 7.1 SP05 or lower. 6. While this design enables maintenance of SKU level data like plant etc., it also introduces another dimension of complexity - the need to ensure SKUs and Material plant information for e.g. is in synch initially before the override changes are made. Special development could be one way to ensure override scenario or similar changes do not violate the integrity of data at the two levels. The following diagram represents this design: Materials [Main Table] Material No. Description. Material Grid No. Grid Description Characteristic Name 1 Characteristic Name 2 Characteristic Name 3 Grid Details [Tuple (mv)] Characteristic Value 1a, Characteristic Value 2a, Characteristic Value 3a Characteristic Value 1b, Characteristic Value 2b, Characteristic Value 3b Grid Plant Data [Tuple (mv)] Plant No SAP AG 8

9 Design Option 4: Material and Grid Header in the Main Table with Associated Grid Details as Attributes of a Taxonomy This design approach is the same as used in the "Matrix application" made available with MDM business content for portal to allow easier integration with SAP for Retail systems. Here the material and SKU again reside in the same main table and SKU characteristics are defined as attributes of taxonomy and the characteristic values as attribute values of the same taxonomy. In the context of a master grid, the grid header and details are both present in the same main table as the material itself. This design approach has the following impact considerations: 1. High data redundancy like the de-normalized model in design option 1 as both Material and SKU data is stored within the same table and are essentially at the same level. 2. Maintenance of Taxonomy data is more complex than maintaining flat lookup tables as used in the other design options. 3. This design option is tightly coupled with the SAP for Retail solution and it might be a challenge to reuse it in other scenarios without a thorough end to end investigation before realization. 4. This design however allows mass maintenance of SKU data either within the same material or across several materials of the same type. 5. Since MDM allows only one taxonomy table linkage per main table, this design results in the characteristic value combinations being used from the same taxonomy hierarchical structure in a repeated fashion. This invites intelligent taxonomy design. The following diagram represents this design: Materials [Main Table] Material No. Description Material Grid No. Grid Description Characteristic 1 Name [Lookup (Taxonomy)] - Characteristic 1 Value Characteristic 2 Name [Lookup (Taxonomy)] - Characteristic 2 Value Characteristic 3 Name [Lookup (Taxonomy)] - Characteristic 3 Value.. Design Option 5: Material and Grid Header in One Main Table with Associated Grids in Another Main Table This design again has certain features unique to MDM and involves multiple main tables. So far all the design options were based on material being in a main or primary table, with SKUs being modeled either as records within the main table itself or as a substructure of the main table. In the context of the master grid, the grid header is present in the same main table as the material and the grid details are present in another main table. This design by default allows a one to one relationship between the grids and its material and reuse of the grids would require a slightly different approach as presented in option 6. This design approach has the following impact considerations: 1. Since the data for SKU is present in a main table, this design allows support for larger volumes of data as can be expected in a one to one relationship between materials and grids. Since reuse of a grid is not allowed, a new material also represents a new grid being introduced with possibly hundreds of records at the grid details level SAP AG 9

10 2. In case there is no requirement to have overrides at Material - Grid combination level, i.e. for a combination of a material along with its grid, the field values at the grid header level would remain same regardless of the material to which the grid is associated; this design can also be used to one grid to many materials type scenario. The alternative design that allows having overrides at the grid as well as at the SKU level is presented in the following section. Here an override represents situations where the same field exists at both the material as well as the SKU level and in cases of SKUs, the value of this field needs to be different from that at the material level. 3. The choice between a qualified table and a tuple rests on the requirement for mass data updates at the SKU level. In case there is a need to allow users to update several SKU records across one or several grids, a tuple type field within a main table does not support this behavior at the time of creation of this document. In such cases either a qualified table should be used if they do not appear to compromise the data model or a custom application should be written to allow for mass maintenance at the tuple level in case tuple is used. 4. As in case of other previous design options, this design also allows only one to one relationship between a material and its grid since the material and grid header are present in the same main table and only the grid details records are in their own table. The following diagram represents this design: Materials [Main Table 1] Material No. Description Material Grid No. Grid Description Characteristic 1 Name Characteristic 2 Name Characteristic 3 Name Grid Details [Main Table 2] Material No. [Lookup (Main table 1)] Characteristic 1 Value Characteristic 2 Value Characteristic 3 Value Grid Plant Data [Qualified / Tuple (mv)] Plant No.. Design Option 6: Material in One Main Table with Master Grid Header in its Own Main Table with Grid Details Data in a Multi-Valued Tuple Using the latest constructs in the form of multi-valued tuple, this design perhaps presents the most flexible, versatile and normalized data model. In this case, the Material and Master Grid data are completely decoupled at the schema level by being present in two separate main tables. The link between the material and the grid can be maintained either through a lookup [Main] type field within the Materials main table or vice versa (in ECC, the Grid table contains the link in the form of the linked material number) or both (this should be carefully evaluated if it s required as bi-directionally linked main tables result in large XML schemas which could be challenging to maintain in syndication as well as the need to delete data from these tables during implementation and testing). Further, the Grid main table only contains the grid header (information common to all the SKUs defined for a grid) and the Characteristics or SKUs are modeled as a multi-valued tuple with all the different characteristic value combinations present as individual records within the tuple. Another level of detail can also be included by nesting another multi-valued tuple within the Grid Details tuple (SKUs level) to accommodate Material Grid Plant level information fields. This will allow having multiple plant level information records for every SKU and this can be further extended to more levels if required. This design approach has the following impact considerations: 1. This design is a highly normalized version of the previous models and prevents redundancy of data to the best extent possible. 2. The cascaded information segregation from Material to Grid to Grid details to Grid plant levels allows for easy visualization and access to the right level of information to the end user whether working in MDM client or through the portal SAP AG 10

11 3. A qualified table could have been another option in place of tuple in case there is no requirement to allow maintenance of another level of information like the material grid plant level data. This is due to the design of qualified tables that do not allow modeling nested structures within them. 4. As stated in the impact considerations of the previous design option, as per the current release of MDM (7.1 SP04 / SP05) at the time of preparing this document, multi-valued tuples do not allow mass maintenance of data across one or multiple main table records, hence alternatives to maintaining multiple records should be considered in case there is a requirement. The support for mass update to tuple data might be available in a future release. 5. Another impact of this design is on the outbound data flow (syndication) from MDM to subscribing destination systems where the normalized data model allows to avoid redundancy of data in the outgoing XML file by keeping only one copy of the material level data, one copy of the grid header which is in turn attached to its own multiple grid characteristic combination records. This ensures there is no overhead of extra data either in the Database, the outgoing XML, the integration broker channels or the receiving destination system s inbound interface. Needless to say, this results in more efficient data processing throughout. 6. On the inbound side also the normalized model allows more efficient import of data during conversion as only one copy of a field value needs to be imported. In most of the previously presented design options, data redundancy where it exists has an impact over processing efficiencies at each point. The following diagram represents this design: Materials [Main Table 1] Material No. Description Material Grid No. [Lookup (Main Table 2)] Master Grid [Main Table 2] Grid No. Grid Description Characteristic 1 Name Characteristic 2 Name Characteristic 3 Name Grid Details [Tuple (mv)] Characteristic Value 1a, Characteristic Value 2a, Characteristic Value 3a Characteristic Value 1b, Characteristic Value 2b, Characteristic Value 3b Grid Plant Data [Tuple (mv)] Plant No SAP AG 11

12 Integration Considerations IDoc types In the original context of this package where Integration of MDM with SAP for AFS has been the focus, the following IDoc types are relevant: IDoc Type Name AFSMATMAS J3AGRI02 Purpose Material Master Data IDoc in the AFS System Master Grid Data IDoc in the AFS System Syndication Sequence In case the syndication is being performed with an SAP for AFS system as the destination, it would be necessary to syndicate the Material Grid data before the Material data for a gridded material can be sent. For a non-gridded material which does not have any association to a grid, the material is syndicated independently. A gridded material syndication will result in an error in case the grid linked to it does not exist beforehand. To ensure adherence to this sequence, specific syndication status flags can be used within the Material table to update and check the syndication status of the grid record when the material is syndicated and prevent material syndication from MDM unless the grid has been successfully syndicated. Synchronous communication between MDM and destination systems can also be considered to capture the status of material and grid syndications and inform the user of the result of syndication from MDM. 2 Vs 3 Dimensional Grid Data and Differences in Syndication While it would be expected that syndication of a 1, 2 and 3 dimensional grids would be possible through the same Syndication map, experience shows that it can be grouped into two different syndications: 1 and 2 dimensional grids are syndicated using one map 3 dimensional grids are syndicated using a separate map Differences in the above two maps are presented in the images below: Mapping for 1 and 2 dimensional grids. The 3 rd dimension here carries NULL values. Mapping for 3 dimensional grids. In this case all the three dimension values need to be populated else the IDoc will result in an error SAP AG 12

13 Related Content SAP Education course ICP 320 SAP Apparel and Footwear Materials Management and Production Planning SAP Education course ICP 310 SAP Apparel and Footwear Sales and Distribution and Allocation Run SAP NetWeaver MDM 7.1 Console Reference Guide on SAP Service Marketplace 2010 SAP AG 13

14 Copyright Copyright 2010 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9, iseries, pseries, xseries, zseries, eserver, z/vm, z/os, i5/os, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM, Power Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are trademarks or registered trademarks of IBM Corporation. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries. Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Business Objects S.A. in the United States and in other countries. Business Objects is an SAP company. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty SAP AG 14