Stock as of a past date

The standard report for historical stock does not read history. It reads current stock and reverses every movement since, at query time, which is why it times out on wide selections and why two runs can disagree.

RuleSnapshot stock daily into a warehouse you own. A past quantity should be a stored fact with one value, forever.

Neverrun period reconciliations on a report whose answer depends on what else was posting while it ran.

◆ The mechanismbackwards from now, at query time, every time.

SAP support note 2000331 states the design plainly: the report reads the current stock level and works backwards through movements to the requested date. Two consequences follow directly.

Wide date ranges and long material lists mean enormous reads, which is where the documented timeouts come from. And postings that occur during the run change the baseline mid-flight, which is why the same request can return different results, also documented, in note 1667353, alongside the negative-quantity artifacts.

None of this is a bug to be patched. It is what recomputing the past from the present costs. The report is fine for a narrow question about one material last week; it is the wrong machine for month-end valuation, audit evidence, or anything concurrent with live postings.

◆ Where it stopsthe requests that outgrow reconstruction.

Request	What happens
Plant-wide stock at month end	A read across every movement since month end for every material. Timeouts and memory dumps at scale, per the support notes.
The same number, twice	Concurrent postings falsify the baseline, so a rerun during business hours may not match. Reconciliation on a moving answer.
Stock value trend by month	Twelve reconstructions, each priced as above. Teams archive spreadsheets instead, which is a snapshot table built by hand.
Anything older than archiving	Archived movements leave the reconstruction incomplete. The past ages out from under the report.

◆ The owned answerstore the quantity once a day, read it forever.

A daily stock snapshot fact ends the recomputation: one row per material, plant, and storage location per day. Month-end valuation reads a partition. The trend is a filter. Concurrent postings cannot change a stored yesterday, and archiving in the source no longer erodes your history, because your history stopped depending on the source.

-- stock on any date, no reconstruction
SELECT plant, material, SUM(quantity) AS on_hand
FROM fct_stock_day
WHERE snapshot_date = DATE '2026-03-31'
GROUP BY 1, 2 ORDER BY 1, 2

The receipt-layer detail the snapshot also carries is what makes inventory aging possible, which the delivered data model cannot do at all. Same table, second page.

Use case

Problem

Historical stock is recomputed backwards from current quantities at query time, so wide requests time out and concurrent postings change the answer mid-run.

What we build

A daily stock snapshot fact by material, plant, and location, with receipt-layer detail retained for aging.

What you get

Month-end quantities that are stored facts: instant to read, identical on rerun, and immune to archiving in the source.

Does your month-end stock number survive a rerun?

We ship the daily snapshot that makes it a stored fact instead of a race.

Talk to us

Terms on this page

SAP: The vendor. Systems, Applications, and Products in data processing.
HANA: SAP’s in-memory database, the platform S/4 runs on.
ERP: Enterprise resource planning, the system of record for operations and finance.
movement: A goods receipt, issue, or transfer changing stock.
storage location: A stock subdivision within a plant.
reconstruction: Deriving a past value by reversing later activity out of the present one.
snapshot: A dated copy of a table state, kept so the past stays queryable.
archiving: Moving old documents out of the live database, beyond the reach of reports.