EBAN table — EBAN Purchase Requisition Item Table

Each row in EBAN represents a single item of a purchase requisition, identified by requisition number BANFN and item number BNFPO. There is no separate requisition header table beyond a header-like grouping implied by BANFN; header and item attributes live together on the item row. A requisition item captures what is being requested (material or free-text description), how much, for which plant and storage location, under which account assignment category, and by when it is needed. The row also tracks the requisition's own lifecycle: creation, release status, deletion indicator, and, if the requisition has been converted, the purchase order number and item that resulted from it. EBAN rows persist after conversion and after deletion; they are not purged, so the table accumulates the full history of every requisition ever raised in the system.

Always restrict on MANDT and never select the full table by BANFN range alone in a production system; requisition numbers accumulate for years and the table can be very large. The most selective starting filters are EKGRP, EKORG, WERKS, and a BADAT date range, or a specific BANFN if it is already known from an EKPO lookup. Avoid selecting on MATNR or MATKL alone across the whole client, those are low-selectivity fields that scan enormous ranges. If searching for open, unconverted requisitions, filter on EBELN being blank and EBAKZ not set, then narrow by EKGRP or WERKS before pulling volume.

To confirm a requisition item was actually converted into a purchase order, select EBAN by BANFN and BNFPO and read EBELN and EBELP directly off the row; both blank means it is still open, both populated means it converted. Cross-check by going the other direction from EKPO where EKPO-BANFN and EKPO-BNFPO match, confirming the PO item genuinely traces back to that requisition item and not a coincidentally reused number from an earlier era.

EBAN continues to exist as a transparent table on S/4HANA and is still written by requisition creation and the purchase requisition Fiori apps as well as the classic transactions. Some newer requisition-related reporting is built on CDS views layered on top of EBAN rather than direct table reads, but the underlying persistence and field structure are essentially unchanged from ECC for the core fields listed here. Custom code and interfaces reading EBAN directly generally continue to work without remapping.

Purchasing questions on EBAN sit with the MM/procurement functional consultant, particularly release strategy and account assignment issues, which usually involve the requester's purchasing group and the release approver setup. Volume or performance questions on the table belong with basis or the ABAP team building the report, since the fix is usually a better selection, not a data correction.

EBKN carries the account assignment detail for each EBAN item and is written alongside it. EKPO is the purchase order item table that EBAN points to once converted, written by the standard purchase order creation transactions and apps. MARA and MARC supply the material master context referenced by MATNR and WERKS. LFA1 supplies vendor master data for any fixed or desired vendor on the requisition.