VBEH table — Schedule Line History for Sales Documents

One row in VBEH represents a historical snapshot of a schedule line that existed before it was updated by a later delivery schedule transmission or manual change, primarily in the context of scheduling agreements used in repetitive manufacturing and JIT/EDI delivery scenarios. When a customer sends a new forecast or JIT delivery schedule, the incoming data overwrites the current schedule line in VBEP; VBEH is where the prior date and quantity for that schedule line are kept so the system, and the consultant, can reconstruct what the schedule looked like before the overwrite. It is not a log of every sales document change. Standard sales orders processed without scheduling agreement functionality typically do not generate entries here. The table matters almost exclusively in automotive and high-frequency EDI supply scenarios where cumulative quantities and delivery performance against a rolling schedule are tracked.

Always restrict by MANDT first, then by VBELN, since the table has no meaningful index for broad, document-less scans. In practice a consultant almost never queries VBEH cold; the entry point is a specific scheduling agreement and item found through VA33 or a JIT monitor, and VBEH is checked afterward to see what a given schedule line used to say. Because the table only fills for scheduling agreement processing with active history recording, a query against a random sales order number will usually return nothing, and that emptiness is expected rather than a sign of a data problem. Volume can be significant for customers with frequent EDI transmissions, so date or change-related restrictions, where available, should be applied rather than pulling the full history for a long-running scheduling agreement.

Symptom: a planner reports that a JIT/forecast delivery schedule quantity for a scheduling agreement item looks different from what was communicated last week. Selection: read VBEP for the current VBELN, POSNR, ETENR to get today's date and quantity, then read VBEH for the same VBELN, POSNR, ETENR to retrieve the prior values recorded before the last inbound schedule update overwrote them. The comparison confirms whether the change came from a genuine new customer transmission or from a manual change inside the sales document.

VBEH continues to exist as a standard table in S/4HANA for scheduling agreement and JIT delivery schedule processing; no confirmed compatibility view replacement is asserted here. The functional behaviour around scheduling agreements and their history tracking has not been observed to change in a way that removes VBEH's role, but any specific release-level statement about restructuring should be verified against the system in question rather than assumed from this page.

This is an SD order-to-cash question, specifically the scheduling agreement or automotive JIT consultant, since VBEH only becomes relevant in that narrow process. Where volume growth or archiving of scheduling agreement history is the concern, basis or data management joins the conversation, but the interpretation of what a given history row means stays with the SD functional owner.

VBAK and VBAP hold the current sales document header and item, VBEP holds the current schedule lines that VBEH's history rows once matched, and VBFA links the scheduling agreement item to any deliveries created against it. VA31, VA32 and VA33 create, change and display scheduling agreements; JIT and forecast delivery schedule inbound processing is what actually writes VBEH as incoming EDI schedules overwrite existing schedule lines.