Explanation:

A. Sourcing via Production (P):
Used when a product is manufactured at a location. It defines the flow from a resource/component level to a specific location (Production Source Header).

C. Unspecified Sourcing (U):
Used for external receipts where the specific source location isn't modeled (e.g., an external vendor). It allows supply to enter the network without a transport or production record.

D. Customer Sourcing Rule (C):
Defines the flow from a distribution center or plant to a customer. This is the final link in the network flow.

Why the other options are incorrect:
B. Sourcing via Demand Prioritization:
This is an algorithm setting used in Response and Supply (Order-Based Planning). While it determines who gets the product first during a shortage, it is not a master data object that defines the physical flow or "sourcing method" of the product itself.

E. Sourcing via Costs:
This is a selection criteria, not a method. In the Supply Optimizer, costs (like transport or production costs) are used as inputs to decide which valid sourcing method is the most economical, but "Costs" is not a sourcing type you configure in master data.

References:
SAP Help Portal: Supply Planning Methods -> Sources of Supply.
SAP IBP Course Material (IBP200): Section on "Supply and Response," specifically the sub-unit on "Master Data for Supply Planning."

Explanation:

To successfully display and edit data across different units (e.g., converting "Eaches" to "Pallets"), SAP IBP requires specific configuration in the planning area and master data.

A. Analytics allow the user to select the target unit of measure:
When creating charts or dashboards in the S&OP Analytics app, the system provides a dropdown to select the "Target UOM." This ensures that data stored in different base units (like Liters and Gallons) can be aggregated into a single, unified view for the user.

C. Units of measure is an attribute of master data type, such as product:
For a conversion to work, the system needs a "Base UOM" assigned to the product. This is typically an attribute of the Product master data type. Without this link, the system wouldn't know which conversion factor to apply to a specific SKU.

D. Units of measure are usually not time-dependent:
In standard IBP configurations, a UOM conversion factor (e.g., 1 Box = 10 Units) is a static physical property. While prices or exchange rates change over time, the physical conversion between units is considered time-independent master data.

Why the other options are incorrect:

B. Units of measure are usually not time-independent:
This is the opposite of option D. As stated above, physical UOM conversions do not fluctuate based on the calendar (unlike currency exchange rates), so they are time-independent.

E. Conversion to the target unit of measure is handled by the SAP IBP Excel add-in:
This is a common "trick" question. While the Excel Add-In displays the converted values, the calculation engine on the SAP IBP server performs the actual conversion math based on the planning area configuration. The Excel client is just the interface, not the calculation engine.

References:
SAP Help Portal: Configuration Guide -> Unit of Measure Conversions.
SAP IBP Course Material (IBP100): Unit on "Master Data and Planning Area Setup."

Explanation:

When you save data in the Excel Add-In or a Web Edit grid, the system immediately triggers one of these methods to push values down:

B. Disaggregation according to an equal split:
This is the simplest method. If you enter "100" at a parent level that has 4 child combinations, the system assigns "25" to each, regardless of their previous values or history.

D. Disaggregation according to a helper key figure:
You can point the disaggregation logic toward a Helper Key Figure (which is not visible to the end-user). This allows for complex, multi-step calculations to determine the distribution weights without cluttering the user interface.

E. Proportional disaggregation by using KF2 in the expression:
This is a common requirement where one key figure (KF1) follows the pattern of another (KF2). For example, you might want "Marketing Spend" to disaggregate proportionally based on the "Sales Forecast" (KF2) values already stored in the system.

Why the other options are incorrect:

A. Disaggregation according to user-defined expression:
While you can use expressions for Calculated Key Figures, the "Disaggregation Expression" field in the configuration specifically requires a reference to a Key Figure (or a simple proportional logic), not a free-form mathematical formula like you would use in a calculation.

C. Disaggregation in batch triggered by an application job:
Disaggregation is an online, real-time process that happens the moment a user saves data or a side-effect of a calculation occurs. Batch jobs (like the Statistical Forecasting or Copy jobs) generate data, but "Disaggregation" itself is a core structural property of how a key figure behaves, not a scheduled task.

References:

SAP Help Portal: Configuration Guide -> Key Figures -> Disaggregation.
SAP IBP Course Material (IBP200): Section on "Model Configuration" and "Key Figure Properties."

Explanation:

To drive values from a higher level of the hierarchy to a lower one, the system must know the "weight" or "proportion" to assign to each child element.

B. Splitting the values from aggregated to detailed level using multiplication by the proportions:
This describes the standard Proportional Disaggregation logic. When a value is entered at the Region level, the system looks at the existing values at the Customer level, calculates their percentage of the total (the proportion), and multiplies the new total by those percentages to distribute the change.

D. Splitting the values from aggregated to detailed level, based on a stored split-factor key figure:
This is a common configuration where you don't want to use the key figure's own history. Instead, you point the disaggregation to a specific Split-Factor Key Figure. This stored key figure holds the exact percentages (e.g., Customer A gets 40%, Customer B gets 60%) used to break down the Regional value.

Why the other options are incorrect:

A. Splitting the values from detailed to aggregated level by using a copy operator:
This is technically backward. Moving data from "detailed to aggregated" is called Aggregation (summing up), not splitting. While a Copy Operator can move data between levels, the term "splitting" specifically refers to the downward movement of data.

C. Splitting the values from aggregated to detailed level, based on the time profile attribute:
Disaggregation logic is based on Key Figures or Equal Splits across master data combinations. While time profiles define the buckets (weeks/months), they do not provide the "split factor" logic needed to distribute values across product or customer dimensions.

References:

SAP Help Portal: Configuration Guide -> Key Figures -> Proportionality and Disaggregation.

Explanation:

Manage Analytics Stories provides a modern, interactive canvas for supply chain visualization. Here is why these three features are central to its capability:

A. Links to external URLs can be embedded in the story:
This is a major functional upgrade. You can add "Hyperlink" objects to a story that point to external sites (like a carrier’s tracking portal or a SharePoint folder) or even back to specific SAP IBP Fiori apps, allowing for seamless navigation between data and execution.

B. The story is structured around one responsive page:
Unlike the older "Dashboards" app which used a fixed grid of tiles, Stories use a responsive layout. This means the charts and tables automatically resize and reposition themselves based on the screen size (mobile, tablet, or desktop) while remaining on a single, scrollable, cohesive page.

C. Specific chart and table filters can be applied within the story:
This allows for high interactivity. A user can apply a "Page Filter" to change the data for the entire story, or a "Widget Filter" to change only a specific chart (e.g., filtering one chart to show only "Region: North America" while the rest of the story shows Global data).

Why the other option is incorrect:

D. Stories must be re-created in each SAP IBP environment:
This is incorrect and would be highly inefficient. Like most SAP IBP configuration objects, Stories can be transported across the landscape (from Development to Quality to Production) using the Transport Model Entities app, or exported/imported via the Content Network.

References:
SAP Help Portal: Reporting and Analytics -> Manage Analytics Stories.
SAP IBP Course Material (IBP100): Unit on "Reporting and Analytics," specifically the section on "Embedded SAP Analytics Cloud."

Explanation:

The Time Series-based Supply Optimizer uses a mathematical programming approach (Linear or Mixed-Integer Programming) to find the most cost-effective solution for the supply chain.

A. Discretization:
This is a setting unique to the Optimizer. It allows you to define whether the algorithm should treat certain variables as integers (e.g., you can't ship 0.5 of a shipping container or produce 0.7 of a batch). Enabling discretization makes the problem a Mixed-Integer Linear Programming (MILP) problem, which is significantly more complex than the standard Linear Programming (LP) used for continuous flow.

C. Global Cost Factors:
Since the Optimizer's primary goal is to minimize total costs, it requires a cost for every action (production, transportation, inventory holding, and stockouts). Global Cost Factors allow you to apply a "multiplier" to these costs across the entire planning area (e.g., increasing the penalty for non-delivery globally) without having to manually update every individual cost key figure.

Why the other options are incorrect:

B. Time Profile Level:
This is not unique to the Optimizer. Both the Heuristic and the Optimizer require you to specify at which level of the time profile (e.g., Month or Week) the planning run should be executed.

D. Processing Mode:
This is a common setting for almost all S&OP operator profiles. It defines whether the run is a "Net Change" or a "Full Repair" (Regenerative) run. Both the Heuristic and the Optimizer utilize these modes to determine how much of the plan needs to be recalculated.

References:
SAP Help Portal: Supply Planning -> Time-Series-Based Supply Planning -> Supply Optimizer.

Explanation:

When you enable a key figure for fixing in the Planning Areas configuration app, you allow planners to "lock" values in the Excel Add-In or Web UI.

D. Fixing is possible for certain period... (Correct):
When a planner fixes a value at an aggregate level (e.g., at the "Product Group" level for the month of October), the system automatically fixes all the underlying "child" combinations (e.g., every individual SKU/Customer combo that makes up that group). This ensures that no calculations or other users can shift the internal proportions of that fixed total.

Why the other options are incorrect:

A. Fixing is possible for key figures with negative values:
By default, SAP IBP does not support the fixing of negative values. Fixing is designed for quantities, prices, or amounts where a "confirmed" plan is expected to be zero or positive.

B. Fixing is possible for a part of key figure value:
Fixing is a binary state for a specific cell (a unique combination of time and master data). You cannot fix "50 units" out of a "100 unit" cell; you fix the entire 100 units for that specific intersection.

C. You can change a fixed key figure only with administrative rights:
This is a common misconception. Fixing is a planner-level tool. Any user whose Business Role includes "Fixing" permissions can fix or unfix values as part of their daily workflow. It is not an IT-restricted administrative function.

References:
SAP Help Portal: User Guide -> SAP IBP, Add-In for Microsoft Excel -> Fixing Key Figure Values.

Explanation:

The Last Period Aggregation (LPA) function is specifically designed for non-cumulative data. It tells the system: "When looking at a higher time level, show me the value from the most recent technical time bucket."

A. Calculating the value of inventory on a weekly basis, using static aggregation from the daily level:
This is the classic inventory scenario. If you are looking at a "Weekly" view, you want to see the inventory level as it stood on the last day of that week (e.g., Sunday). LPA ensures the system pulls the Sunday value rather than summing up Mon-Sun.

D. Calculating the value of inventory on any level from the time profile, ensuring flexibility of calculation:
LPA is versatile. Whether you are aggregating from Days to Weeks, Weeks to Months, or Months to Years, it ensures the "Closing Balance" logic remains consistent across any level of the time profile hierarchy you choose to view in your Excel planning view.

Why the other options are incorrect:

B. Calculating how many periods inventory is going to last:
This describes Days of Supply or Coverage logic. While this uses inventory as an input, it is a complex calculation (comparing inventory vs. future demand) and not a simple "Aggregation" function like LPA.
C. Searching for and returning the last not-null value:
This describes the IBP_LAST_VALUE function (or similar "Last Known Value" logic). While it sounds similar, "Last Period Aggregation" specifically looks at the last period in the time bucket, regardless of whether that value is null or zero.

References:
SAP Help Portal: Configuration Guide -> Time-Based Aggregation -> Last Period Aggregation.

Explanation:

SAP IBP for Demand is designed to move beyond manual forecasting into a more "touchless" planning environment.

A. Automated, exception-based processing:
IBP allows planners to focus only on what matters. By using Alerts and Custom Alerts, the system can automatically flag products where the forecast error is too high or where demand spikes occur, allowing the planner to manage by exception rather than reviewing every single SKU.

B. Statistical analysis using predictive analytics tools:
This is the core of the module. It includes a library of statistical models (Exponential Smoothing, Regression, Croston’s, etc.) and advanced Machine Learning (Gradient Boosting, Demand Sensing) to analyze historical patterns and predict future requirements.

E. Embedded, on-the-fly demand analytics:
Because IBP is built on SAP HANA, users can perform real-time analysis. You can change a filter or aggregate data from SKU to Product Group, and the analytics (charts and dashboards) update instantly without needing to run a background data-crunching job.

Why the other options are incorrect:

C. Determination of Coefficient of Variation (CV):
While IBP can calculate CV, this is primarily a core capability of the SAP IBP for Inventory module (used for demand variability analysis to set safety stock), rather than a "key capability" defining the Demand module itself.

D. Classifying demand into zones:
This terminology usually refers to Buffer Zones within Demand-Driven Replenishment (DDMRP). While IBP supports DDMRP, "zones" is not a standard "key capability" of the general Demand forecasting process.

References:
SAP Help Portal: SAP IBP for Demand -> Demand Planning Processes.

Explanation:

Managing data across versions is essential for maintaining a consistent planning environment.

B. Copy key figure data from any version to any version:
Using the Copy Operator (Advanced) or the Copy Version Data application job, you can move data between any defined versions. For example, you can copy the "Final Forecast" from the Base Version into an "Upside Version" to begin a simulation. You have the flexibility to copy specific key figures or all of them.

C. Copy master data from base version to other version:
Some versions are "Version-Specific Master Data" enabled. This allows you to have different master data (like a new sourcing lane) in a simulation. The system provides a specific application job, Copy Master Data between Versions, which allows you to seed your simulation version with the existing master data from the Base Version.

Why the other options are incorrect:

A. Delete key figure data for a date range for all versions at once:
While you can delete data, the Purge Key Figure Data job usually requires you to specify which version you are targeting. Deleting across all versions simultaneously for a specific range is not a standard, single-action configuration feature for safety reasons (to prevent accidental data loss in the Base Version).

D. Run an application job to purge obsolete versions:
You do not "purge" versions using an application job in the same way you purge data. To remove an obsolete version, a configurator must delete it through the Planning Areas or Versions configuration app. While you can purge data within a version via a job, the version container itself is a configuration object.

References:
SAP Help Portal: Model Configuration -> Versions.
SAP IBP Course Material (IBP200): Unit on "Version Management and Master Data."
Application Help: Review the Copy Master Data between Versions job documentation in the Job Definitions app.

Explanation

The Check Mode performs "sanity checks" on the structural integrity of your model. Here is why these three are the core triggers:

B. It reports input key figure for which no related master data exists:
This is one of its most critical functions. If you have a forecast (Demand) for a Product-Location combination in a key figure, but that specific combination does not exist in the Location Product master data, the Check Mode will flag it. Without the master data "anchor," the supply engine cannot process those values.

D. It checks whether the heuristic detects cycles:
A "cycle" occurs when Product A at Location 1 is sourced from Location 2, but Location 2 is also sourced from Location 1 (an infinite loop). The Check Mode identifies these circular dependencies which would otherwise cause the Supply Heuristic to fail or run indefinitely.

E. It checks whether the sourcing in the Production Source Item master data type exists:
It validates the BOM (Bill of Materials) structure. If you have a Production Source Header (the "recipe") but no corresponding Production Source Items (the components/ingredients), the system cannot calculate component requirements. Check Mode identifies these "empty" production sources.

Why the other options are incorrect:

A. It checks customer sourcing rules connectivity:
While customer sourcing is important, the Check Mode doesn't necessarily validate the "completeness" of the network flow for every demand; it focuses more on the existence and validity of the master data records themselves rather than the strategic reach of the network.

C. It checks whether location resources form a cycle:
This is a distractor. Cycles are detected between nodes (Location Products) as stated in Option D. Resources themselves are capacities tied to locations and don't "form cycles" in the same topological way that sourcing lanes do.

References:
SAP Help Portal: Time-Series-Based Supply Planning -> Check Mode.
SAP IBP Course Material (IBP200): Unit on "Supply Planning Algorithms," specifically the "Troubleshooting and Check Mode" section.

Explanation:

The Advanced Dashboards app is designed to provide both high-level visibility and the ability to investigate the root causes of supply chain issues.

A. Use drill-down functionality:
This is a core feature of advanced visualization. If you see a spike in "Total Revenue" on a global chart, you can click on that data point to "drill down" into more specific levels, such as Product Family or Region, without leaving the dashboard.

C. Link two analytics charts:
This provides synchronized filtering. For example, you can link a chart showing "Demand Forecast" with a chart showing "Inventory Levels." When you filter the first chart for a specific product, the second chart automatically updates to show the inventory for that same product.

E. Display all assigned analytics on a single UI:
The primary purpose of a dashboard is to act as a "cockpit." It allows you to bring together multiple independent Analytics Charts (created in the Analytics app) and arrange them on a single screen to provide a holistic view of the business process.

Why the other options are incorrect:

B. Add Process instances:
Process instances are managed in the Manage Process or Process Modeling apps. While dashboards are used to monitor a business process, adding or creating the actual process steps and instances is a function of the S&OP collaboration tools, not the analytics visualization engine.

D. Rename the charts:
While you can change the title of a chart within the dashboard configuration, the actual renaming of the source analytics object is done in the Analytics app. In the Dashboards app, you are primarily "consuming" and "organizing" existing objects rather than editing their core metadata.

References:
SAP Help Portal: Reporting and Analytics -> Dashboards.
SAP IBP Course Material (IBP100): Unit on "Reporting and Analytics," specifically the section on "Dashboard Configuration."