The planning model: areas, key figures, versions

Everything a planner sees in IBP comes from the planning area. SAP's learning material calls it the central configurable object: it brings together master data types, attributes, the time profile, key figures, planning levels and versions, and it defines how data is stored, calculated and aggregated. People often call it the planning model. If you can read a planning area, you can predict what a planning view will show and why.

The building blocks

Stored and calculated key figures

A stored key figure holds data that is loaded or typed in: sales history from S/4HANA, a marketing adjustment entered by a planner. A calculated key figure is derived by a calculation from other key figures, for example consensus demand from the statistical forecast plus adjustments. Calculations can run at different planning levels, and that is where many surprises come from: a key figure calculated at product / location / month and then disaggregated to customer may not equal the sum you expect from customer-level inputs.

Worked example: aggregation and disaggregation

Contoso stores consensus demand for CMC-ALT-100 at product / location / customer / month. For Detroit (1710) in March, the customer values are Great Lakes Fleet Services 1,200, other fleet customers 1,800 and aftermarket 1,000, a total of 4,000 pieces. Sunita opens a view at product / location level and changes 4,000 to 4,400. IBP must push the extra 400 down to customers. With proportional disaggregation based on the existing values, Great Lakes gets 1,320, other fleet 1,980 and aftermarket 1,100. If the key figure's disaggregation mode were "equal split", each would get about 133 more instead. Same total, different customer plans.

Testers should record the disaggregation mode of every key figure planners edit, then test one change at an aggregate level and check the lower-level result against a hand calculation. This is the planning equivalent of checking a pricing condition.

Versions and scenarios

When a planning area is activated, the baseline version exists automatically. Administrators can add versions, such as an Upside version for a large fleet tender, and choose which key figures each version carries. Scenarios are lighter: a planner creates a what-if on top of a version, shares it with colleagues, and either promotes the changes or discards them. A frequent defect is a planner saving into the wrong version or scenario and reporting "lost" data; the data is there, in another data set.

Step by step: reading a planning area before you test

1. Open the planning area in the model configuration apps and note its status (active or inactive) and the time profile it uses.
2. List the master data types and their key attributes. For CMCPA01: product, location, customer, and the compound types location product and customer product.
3. Open the key figures planners will edit and record, for each, whether it is stored or calculated, its base planning level and its disaggregation settings.
4. Follow every calculated key figure back to its inputs and note at which level the calculation runs.
5. List the versions and which key figures each one carries; an Upside version without the capacity key figure cannot show capacity.
6. Record all of this in the key figure catalog and agree it with Sunita before writing test cases.

This reading takes a morning and saves days. Most planning defects reported by testers in early cycles at Contoso were not defects at all: the tester expected a value at customer level for a key figure that was stored only at product / location level, or looked at the baseline while the planner worked in a version.