Select Two (Multi-Select) Questions

Assign Wave Template to Storage Type

Why it fails: Wave templates are determined based on wave types and conditions defined in the wave determination table, not by direct assignment to a storage type. Assigning them to storage types is not a functional requirement and would create an incorrect architectural dependency between volume processing logic and physical storage layout.

Configure Storage Bin Sorting

Why it fails: Storage bin sorting defines the optimal path for warehouse workers during picking operations. While important for performance, it is unrelated to the logical grouping of deliveries into waves. Incorrectly linking these concepts confuses the system's task sequencing logic with the higher-level outbound delivery scheduling functionality required for waves.

Enable Cross-Docking

Why it fails: Cross-docking is a mechanism to bypass storage by moving goods directly from inbound to outbound. While waves can include cross-docking items, enabling it is not a prerequisite for basic wave management. This configuration is entirely separate and does not influence the core logic of wave assignment or release.

The physical inventory process in EWM does not support the use of serial numbers.

Why it fails: EWM physical inventory does support serial numbers. When counting, you can enter serial numbers for serialized products, and the system validates them. This ensures accurate tracking of individual items. Serial numbers are integrated into the inventory process, allowing for detailed verification and adjustment.

Physical inventory in EWM is only possible for storage bins with a special stock indicator.

Why it fails: Physical inventory can be performed for any storage bin that contains stock, regardless of special stock indicators. Special stock indicators are used for consignment or customer stock, but they do not restrict the ability to count. EWM allows counting of all stock types as long as the bin is not blocked for inventory.

The physical inventory count results are posted directly to the ERP system without any EWM-specific adjustments.

Why it fails: In SAP EWM, physical inventory differences are first recorded in EWM and then replicated to ERP. EWM performs its own adjustments to the warehouse stock, and then the differences are sent to ERP to update the inventory there. Direct posting without EWM adjustments is incorrect because EWM maintains its own stock separately.

Triggering a physical warehouse task for stock movement.

Why it fails: A posting change is, by definition, a non-physical movement. If a physical task were required, a warehouse request for stock transfer would be used instead. The posting change document does not generate warehouse tasks for physical relocation of goods between different storage bins.

Calculating the total warehouse storage capacity.

Why it fails: Capacity calculation is a background process managed by the warehouse management system based on bin master data. The posting change document is a transactional record for inventory attribute adjustments and has no functional capability or responsibility related to calculating total warehouse capacity or storage utilization.

Direct manual generation of general ledger accounting entries for warehouse labor depreciation.

Why it fails: Advanced wave management orchestrates picking, packing and staging; it posts no general ledger entries, which flow through FI postings from warehouse movements. The option tempts because warehouse labour costs do reach finance, but manual GL creation for depreciation sits outside EWM wave functionality entirely.

Automatic conversion of physical storage bins into production work centers during wave release.

Why it fails: Wave release groups warehouse documents for picking; it never reclassifies physical storage bins as production work centres, a master-data change belonging to production planning. The option tempts because waves do trigger downstream task creation, yet bin-to-work-centre conversion is not a wave management function.

The storage type search sequence for putaway.

Why it fails: The storage type search sequence is determined by the Putaway Control Indicator in the product master, not directly by the WPT. While the WPT can influence which putaway strategy is used, the actual search sequence is a separate configuration. Therefore, this setting is not directly controlled by the WPT.

The default destination storage bin for putaway.

Why it fails: The default destination storage bin is not directly set in the WPT; it is determined by the putaway strategy and storage bin determination rules. The WPT may influence which strategy is used, but it does not specify a default bin. This is a common misconception, as the WPT focuses on process steps rather than bin determination.

The number range for warehouse tasks.

Why it fails: Number ranges for warehouse tasks are defined at the warehouse number level, not at the WPT level. The WPT does not control number assignment for warehouse tasks; instead, it determines process steps and task creation rules. Number ranges are configured separately and apply to all warehouse tasks within a warehouse number.

A storage section defines the maximum weight and volume that can be stored in a bin.

Why it fails: The maximum weight and volume are defined in the storage bin master record, not in the storage section. The storage section groups bins but does not carry capacity constraints. Capacity checks are performed at the bin level based on bin master data.

A storage section determines the warehouse process type for putaway and picking.

Why it fails: The warehouse process type is determined by the warehouse process type determination rules based on document type, movement type, and other factors. It is not determined by the storage section. The storage section is a structural grouping of bins, not a control for process types.

A storage section is mandatory for every storage type and must be created before bins can be assigned.

Why it fails: A storage section is not mandatory for every storage type. Some storage types may not require sections, especially if they are small or homogeneous. Bins can be assigned directly to a storage type without a section. Sections are optional and used for more granular control.

Cross-docking requires the creation of a separate cross-docking warehouse process type for each material to be cross-docked.

Why it fails: Cross-docking does not require a separate warehouse process type per material. Instead, a single cross-docking process type can be used, and the system determines eligibility based on delivery dates and other criteria. Creating per-material process types would be inefficient and is not standard practice.

Cross-docking requires manual creation of a warehouse order for the movement from inbound to outbound staging area.

Why it fails: Cross-docking tasks are typically generated automatically based on the cross-docking process type and can be included in warehouse orders automatically. Manual creation is not a requirement; the system can create warehouse orders for cross-docking movements as part of the standard process.

Cross-docking in EWM is only possible for full pallets and cannot be used for partial quantities.

Why it fails: Cross-docking in EWM can handle both full pallets and partial quantities. The system can split handling units or quantities to fulfill outbound demands. Restricting to full pallets would limit flexibility and is not a limitation of the functionality.

It replaces the need for the /SCWM/MON transaction by providing a Fiori-based interface only.

Why it fails: The Warehouse Management Monitor is accessible via the /SCWM/MON transaction and also through Fiori apps, but it does not replace the transaction entirely; both interfaces coexist. Claiming it is Fiori-only is incorrect. Supervisors can use either the classic transaction or Fiori apps depending on their setup and preferences.

It automatically creates warehouse tasks for outbound deliveries that are not yet released.

Why it fails: The Warehouse Management Monitor is a monitoring and intervention tool; it does not automatically create warehouse tasks for unreleased deliveries. Task creation occurs when the warehouse request is released, either manually or via background job. The monitor can be used to release requests, but it does not autonomously generate tasks.

It can only display data for the warehouse to which the user is currently logged on, with no cross-warehouse visibility.

Why it fails: The Warehouse Management Monitor can be configured to allow cross-warehouse visibility if the user has the necessary authorizations and the monitor is set up accordingly. It is not limited to a single warehouse. Restricting it to one warehouse would be a configuration choice, not an inherent limitation, so this statement is false.

KPIs in the Warehouse Monitor can only be displayed in a graphical dashboard, not in list form.

Why it fails: The Warehouse Monitor primarily presents data in list form with various nodes and columns. While graphical dashboards may be available through other tools like SAP Fiori apps, the Warehouse Monitor itself is list-based. KPIs are shown in lists, and users can customize the layout to include KPI columns.

The Warehouse Monitor automatically creates alerts when a KPI exceeds a threshold.

Why it fails: The Warehouse Monitor does not automatically create alerts based on KPI thresholds. Alert creation is typically handled through the Exception Handling framework or other monitoring tools. The Warehouse Monitor is primarily for analysis and drill-down, not for automated alerting.

KPIs in the Warehouse Monitor are updated in real time without any delay.

Why it fails: While the Warehouse Monitor provides near real-time data, it is not strictly real-time; there can be a slight delay depending on system load and data refresh settings. KPIs are typically refreshed at defined intervals or upon manual refresh, so they may not reflect the absolute latest transaction instantly.

Automated task assignment based on resource skills

Why it fails: Automated task assignment based on resource skills is a function of the Labor Management or Task Management components, not the Warehouse Management Monitor. The monitor is for viewing and analyzing data, not for executing task assignments. While it can display task-related KPIs, it does not automatically assign tasks, so it does not meet the requirement for monitoring KPIs.

Integration with SAP Analytics Cloud for advanced reporting

Why it fails: Integration with SAP Analytics Cloud is possible for advanced reporting and analytics, but it is not a built-in feature of the Warehouse Management Monitor itself. The monitor provides real-time operational data, while SAP Analytics Cloud is a separate tool for strategic analysis. The supervisor needs immediate KPI visibility within EWM, which is delivered by the monitor's own capabilities, not by external integration.

Graphical display of warehouse layout with HU locations

Why it fails: While the Warehouse Management Monitor can display a graphical warehouse layout, this is not a core feature for monitoring KPIs like open tasks and resource utilization. The graphical view is primarily for spatial orientation and HU tracking, not for aggregating performance metrics. It may complement KPI monitoring but does not directly provide the required real-time KPI data.

Serial number profiles are defined at the warehouse level and apply to all storage types.

Why it fails: Serial number profiles are defined at the material level, not the warehouse level. Each material can have a different serial number profile that determines when serial numbers are required. The profile is assigned in the product master. While the profile can be the same for multiple materials, it is not a warehouse-wide setting. Therefore, this statement is false.

Serial numbers are mandatory for all materials in EWM.

Why it fails: Serial numbers are not mandatory for all materials. They are only used for materials that are flagged as serialized in the product master. The serial number profile determines whether a material requires serial numbers during various processes. For non-serialized materials, serial numbers are not captured, and the system does not enforce their entry.

Serial numbers can only be entered manually during outbound delivery creation.

Why it fails: Serial numbers can be entered at various stages, not only during outbound delivery creation. They can be captured during goods receipt, putaway, picking, or packing. The system supports automatic assignment and scanning. Restricting to manual entry during outbound delivery creation would be inefficient and error-prone, so this statement is incorrect.

It automatically creates warehouse tasks for all storage types in the sequence.

Why it fails: The storage type search sequence does not create warehouse tasks; it only determines the order in which storage types are searched. Warehouse tasks are created after a suitable bin is found, based on the search sequence and other strategies. The sequence itself is a configuration that guides the system, but it does not trigger task creation. Task creation is a separate step in the process.

It overrides the storage bin determination logic and directly assigns a bin.

Why it fails: The storage type search sequence does not directly assign a bin; it determines the storage type. After a storage type is selected, the system then uses bin determination logic (e.g., storage bin sorting, capacity check) to find a specific bin within that storage type. The sequence is a higher-level filter, not a direct bin assignment mechanism. Bin assignment requires additional strategies.

It is used exclusively for outbound processes to determine the picking storage type.

Why it fails: The storage type search sequence is used for both inbound (putaway) and outbound (stock removal) processes. It is not exclusive to outbound. For putaway, it helps find a destination storage type; for stock removal, it helps find a source storage type. This dual use makes it a versatile tool for warehouse management, ensuring that both putaway and picking follow defined rules.

Physical inventory documents are created based on the warehouse number.

Why it fails: Physical inventory documents in EWM are not created based on the warehouse number alone. They are created for specific storage bins or handling units, depending on the physical inventory method. The warehouse number is part of the organizational structure, but the document creation is more granular, focusing on the bins or HUs to be counted.

Physical inventory must be performed for all storage bins at the same time.

Why it fails: Physical inventory in EWM can be performed for selected storage bins or storage types, not necessarily for all bins simultaneously. You can define scope and schedule counts as needed. This flexibility allows for phased inventories without disrupting warehouse operations. Performing for all bins at once is not a requirement.

Physical inventory results are posted directly to the material master in SAP S/4HANA.

Why it fails: Physical inventory results in EWM are posted to the EWM stock, not directly to the material master in SAP S/4HANA. The EWM stock is then replicated to SAP S/4HANA inventory management. The posting is done via the physical inventory document, and adjustments are made to the EWM stock, which then updates the ERP system.

Returns in EWM must always be processed as outbound deliveries because they involve shipping goods back to the vendor.

Why it fails: Returns from customers are inbound to the warehouse, not outbound. Outbound deliveries are used for shipping goods to customers. Processing customer returns as outbound deliveries would be incorrect because it would initiate a shipment rather than receiving goods. The scenario describes receiving returned goods for inspection, which is an inbound process.

The returns process in EWM does not support quality inspection; inspection must be done in SAP QM before creating an EWM inbound delivery.

Why it fails: EWM supports inspection within the warehouse via inspection storage types and warehouse process types. You can route returns to an inspection area and perform inspection activities. While SAP QM can be integrated, EWM itself can handle inspection steps. Claiming that inspection must be done in QM before creating an inbound delivery is incorrect because EWM can manage the inspection process internally.

After inspection, scrapping returned goods requires a separate outbound delivery to remove them from the warehouse.

Why it fails: Scrapping in EWM is typically done via an internal warehouse process, such as a scrapping warehouse task or a posting change, not an outbound delivery. An outbound delivery is for shipping to a customer or vendor. Using an outbound delivery for scrap would incorrectly trigger shipping processes and not reflect the internal disposition. Scrap is usually handled by moving goods to a scrapping storage type or using a scrapping warehouse task.

Storage sections are defined at the warehouse number level and are shared across all storage types.

Why it fails: Storage sections are defined at the storage type level, not the warehouse number level. Each storage type can have its own storage sections. This allows different storage types to have different sectioning schemes based on their specific characteristics. They are not shared across all storage types.

Storage sections are only relevant for inbound putaway and are ignored during outbound picking.

Why it fails: Storage sections are relevant for both putaway and picking. During picking, the system can use storage sections to optimize the picking path or to prioritize picking from certain areas. The storage section can be considered in the storage type search sequence for both processes, depending on configuration.

Storage sections are mandatory for every storage type and must be defined before storage bins can be created.

Why it fails: Storage sections are optional. You can create storage bins without assigning them to a storage section. However, if you want to use storage sections in the search sequence, you must define them and assign them to storage bins. They are not a prerequisite for bin creation.

It determines the warehouse number for the process.

Why it fails: The warehouse number is an organizational unit that is independent of the warehouse process type. The process type is defined within a warehouse number, but it does not determine which warehouse number is used. The warehouse number is determined by the delivery or the organizational assignment, not by the process type.

It defines the default resource for executing warehouse tasks.

Why it fails: The default resource is not defined in the warehouse process type. Resources are assigned to warehouse tasks based on the resource management configuration and the task's requirements, such as equipment type. The process type may influence the task creation, but it does not directly assign a default resource.

It defines the number of warehouse tasks that can be created for a delivery.

Why it fails: The number of warehouse tasks created for a delivery is determined by the delivery items, quantities, and the warehouse process type's settings for task creation, but the warehouse process type does not directly define a fixed number. It influences whether tasks are created at the item level or HU level, but it does not set a specific count. This statement is misleading.

Configure the storage bin master for the high-rack storage type with a capacity check that allows overflow to bulk storage.

Why it fails: The storage bin master does not have a setting to allow overflow to another storage type. Capacity checks are performed per storage bin, and if a bin is full, the system simply tries the next bin in the same storage type or moves to the next storage type in the search sequence. There is no overflow configuration in the bin master.

Activate the 'Mixed Storage' indicator for the bulk storage type to allow different materials.

Why it fails: Mixed storage allows different materials to be stored in the same bin, but it does not influence the storage type search sequence. The requirement is about searching storage types in a specific order, not about allowing mixed materials. Activating mixed storage is irrelevant to the search sequence and does not help achieve the desired putaway behavior.

Define a storage section search sequence for the high-rack storage type only.

Why it fails: A storage section search sequence is used within a storage type to prioritize storage sections. It does not control the transition from one storage type to another. For the requirement, you need a storage type search sequence, not a storage section search sequence. The storage section sequence is optional and only refines bin selection within a storage type.

The storage type for cross-docking must be a standard putaway storage type with a putaway strategy assigned.

Why it fails: Cross-docking typically uses a dedicated storage type or a cross-docking area, often with a special role. It does not require a standard putaway storage type with a putaway strategy. In fact, the goal is to avoid putaway, so the storage type is usually configured differently to allow direct movement.

Cross-docking is only possible if the inbound delivery is created in EWM directly, not replicated from ERP.

Why it fails: Cross-docking can be used with both EWM-created and ERP-replicated inbound deliveries. The replication process does not prevent cross-docking. In fact, in a decentralized scenario, inbound deliveries are typically created in ERP and replicated to EWM, and cross-docking can still be applied.

Cross-docking in EWM can be executed without creating a warehouse task for the movement from inbound to outbound.

Why it fails: Cross-docking still requires warehouse tasks to move the goods from the inbound area to the outbound area. The difference is that the goods are not put away into a storage bin; instead, a warehouse task moves them directly to the outbound staging area. Warehouse tasks are always needed to execute physical movements.

The storage section is defined at the warehouse number level and applies to all storage types.

Why it fails: The storage section is defined per storage type, not at the warehouse number level. It is a subdivision of a specific storage type. Therefore, it does not apply globally to all storage types within a warehouse.

The storage section determines the putaway strategy to be used for a product.

Why it fails: The putaway strategy is determined by the warehouse process type and the storage type, not by the storage section. The storage section only refines the bin selection within a storage type. It does not control which putaway strategy is applied.

The storage section is mandatory for every storage type in EWM.

Why it fails: The storage section is not mandatory. You can use storage sections only when needed. If a storage type does not have storage sections defined, the system skips the storage section search step. Therefore, it is optional and depends on the warehouse design.

The storage type search can only consider storage types that have the same storage section as the product's storage section indicator.

Why it fails: The storage type search is not limited to storage types with the same storage section. It searches across storage types according to the search sequence. The storage section search is a separate step that refines the bin selection within a storage type. The storage type search can include storage types with various storage sections, depending on the sequence.

The storage type search is performed before the storage section search, and the storage section search then selects the specific storage bin.

Why it fails: The storage type search determines the storage type, and then the storage section search determines the storage section within that storage type. Finally, the bin search selects the specific bin. The order is storage type search, then storage section search, then bin search. This option incorrectly states that storage section search selects the bin; it actually narrows down the section, and then bin search selects the bin.

The storage type search sequence can be defined with a maximum of 10 storage types.

Why it fails: There is no fixed maximum of 10 storage types in a search sequence. The number of storage types in a search sequence is configurable and can be more or less than 10. The limit depends on the system and customizing, but it is not a standard restriction. This statement is incorrect.