EINE table — Purchasing Info Record - Purchasing Org Data

Each row in EINE represents the conditions a vendor offers for a material (or service) for one purchasing organization, one info record category, and optionally one plant. The same info record number in EINA can have several EINE rows: one plant-independent row for the purchasing org as a whole, plus separate plant-specific rows if plant conditions were maintained, plus separate rows again if the same vendor-material combination is also relevant as subcontracting or consignment (a different ESOKZ). The row stores the net price and price unit last entered or derived from the last purchase order or quotation, the planned delivery time used to propose the PO delivery date, the order unit, rounding quantity, minimum quantity, and over/under-delivery tolerances. It does not store the vendor, material or plant master data itself; those live upstream in EINA and the material/vendor masters.

MANDT is the client field and should always be implicit in any tool-based selection. INFNR alone is not selective enough because one info record can carry several EINE rows across purchasing organizations, categories and plants; always add EKORG, and add WERKS and ESOKZ whenever the business question is plant- or category-specific. Selecting on MATNR or LIFNR directly does not work because those fields sit on EINA, not EINE, so any cross-table pull has to join through INFNR first. The table itself is not huge in most landscapes, but a selection with only INFNR against a vendor with many plant-specific entries will return more rows than expected and the wrong one may get picked up by a downstream program that assumes a single hit.

To confirm which price and delivery time a purchase order item should have defaulted to from the info record, take the vendor and material from the PO, find INFNR in EINA for that LIFNR/MATNR pair, then select EINE with that INFNR restricted to the PO's EKORG, the PO's WERKS if a plant-specific row exists, and the ESOKZ matching the procurement type (standard vs subcontracting vs consignment). Compare NETPR/PEINH there against the PO item's condition record, not against what the PO item currently shows, since the info record price only proposes a default and may since have been overridden.

EINE remains a transparent table on S/4HANA with the same role and largely the same shape as in ECC. Reporting and app layers increasingly read purchasing info record data through CDS views rather than direct table access, and condition-based price determination for info records has become more common as the default, which shifts more of the 'live' pricing logic away from EINE-NETPR toward the pricing condition tables even though EINE still stores the info record's own reference price and terms.

The MM/purchasing functional lead owns interpretation questions about which EINE row a given purchasing organization should be using and why a price default did or did not appear on a PO. Master data or procurement operations teams own the maintenance process for info records; a data question that turns out to be a maintenance gap (missing plant-specific row, wrong ESOKZ) routes back to them, not to a technical fix.

EINA carries the vendor- and material-level general data for the same info record and is maintained together with EINE through the standard info record maintenance transaction. EKPO can reference an info record via INFNR when a PO item is created against one. EORD holds source list entries that often point at the same info record. LFA1 and MARA supply the vendor and material master data that EINA links to.