EORD table — Source List Table for Material and Plant

One row in EORD represents one source-of-supply entry for a material at a specific plant, valid for a defined date range. The entry names a vendor (and optionally a specific contract or scheduling agreement item) as an allowed source for that material-plant combination during that period. Multiple rows can exist for the same material and plant with non-overlapping or overlapping validity periods, each pointing to a different vendor or a different contract with the same vendor. The table is maintained through the source list transactions and is consulted by purchase requisition and purchase order creation, by MRP-driven procurement proposals when the source list indicator on the material master is switched on, and by outline agreement distribution logic when a single vendor is marked as the fixed source.

Always restrict on MANDT, then on MATNR and WERKS together, since those two fields drive the index and the table can carry many rows per material across plants. Do not select on LIFNR alone across the whole client; it is not the leading part of the key and a full scan on a large installation is slow. Once MATNR and WERKS are fixed, the remaining rows for that combination are few, so filtering further on VDATU and BDATU against the transaction date pinpoints the entry actually in force. Remember that VDATU and BDATU are stored as character dates in the internal format, so compare against a date variable of the same type rather than a string literal typed by hand.

Symptom: a purchase requisition for a material at a plant is being blocked or auto-sourced to a vendor the buyer did not expect. Select EORD where MATNR equals the material, WERKS equals the plant, and the requisition creation date falls between VDATU and BDATU. If exactly one row is returned and FLIFN is set, that vendor is the mandatory fixed source and the system behaviour is by design, not a bug. If two or more rows overlap the date, the source list itself is inconsistent and needs correction before blaming the transaction.

EORD is unchanged as a transparent table in S/4HANA and continues to be maintained through the same source list transactions. There is no compatibility view replacement in general use for this table; the underlying source list logic in requisition, purchase order and MRP processing still reads it directly. Consultants moving from ECC should not expect a CDS-based replacement here, unlike some other classic MM tables.

The buyer or purchasing team owns the content of the source list, since it reflects a sourcing decision. The MM functional consultant owns whether the material master and plant settings actually make the source list relevant to procurement. A data or basis question about EORD growth or index behaviour on a very large material base is an MM technical or basis matter.

Source list entries are maintained through the standard source list transactions and are closely tied to purchasing info records in EINA and EINE, to outline agreements in EKKO and EKPO when a specific contract is referenced, and to material and plant data in MARA and MARC that determine whether the source list is actually enforced. Vendor master data in LFA1 resolves the vendor named in each entry.