ME3N — Purchase Orders by Vendor List Display

ME3N lists purchase orders selected primarily by vendor, pulling header data from EKKO and item data from EKPO, with schedule line and history information joined in for delivery and invoice status. The structural fact that explains most confusion: ME3N is not a separate program with its own logic, it is an older, more restricted selection screen sitting on top of the same list-display report family that also produces ME2N, ME2M, ME2L and the rest of the ME2x/ME3x set. The fixed selection fields on ME3N (vendor, purchasing organization, plant, document type, the WE10x/RE10x delivery and invoice completion switches) are the same fields that drive every sibling transaction, just arranged differently. Consultants who learn one of these transactions well can operate all of them, because the differences are cosmetic screen layout, not underlying selection logic.

ME3N is reached for whenever the starting point of an investigation is a vendor rather than a PO number, a material, or an account assignment: checking all open orders with a supplier before a blocking decision, reviewing outstanding deliveries during a vendor escalation, or pulling a quick list before a goods-receipt or invoice cleanup exercise. It sits in the monitoring layer of procure-to-pay, between order creation and the eventual goods receipt and invoice verification steps. On systems with Fiori adoption for purchasing, the 'Manage Purchase Orders' app covers the same use case with better filtering and export, and is generally preferred for ad hoc single-user lookups; ME3N and its siblings remain the tool of choice for mass selections run with saved variants, background jobs, or when a consultant needs the exact same list logic a legacy report or interface relies on.

To confirm what a user is seeing, run SE16 on EKKO filtered on LIFNR and BUKRS/EKORG to get the candidate PO numbers, then join manually against EKPO on EBELN filtered on LOEKZ (deletion indicator) blank to exclude deleted items. Cross-check EKET for the same EBELN/EBELP to see whether the still-to-be-delivered quantity is actually zero, which explains why a PO disappears from ME3N when the completion switches are set to 'open only'. This isolates whether the transaction is filtering correctly or the master data itself is missing the expected line.

ME3N runs on S/4HANA largely unchanged; it is the same GUI list-display report against the same underlying tables. The Fiori 'Manage Purchase Orders' app is the modern equivalent for single-case lookups and offers richer filtering, but ME3N and its ME2x/ME3x siblings remain fully supported and are still the practical choice for saved variants, mass extracts, and batch-driven monitoring where a Fiori app's interactive filtering adds no value.

This is a functional MM/purchasing transaction; missing or unexpected results are almost always a selection-screen or authorization matter, not a technical defect. A good handover to Basis or security includes the exact vendor, purchasing org and plant used in the selection, the completion switch settings, and the specific PO/item expected but not shown, so authorization can be checked against the actual selection rather than guessed at.

ME2L and ME2M cover the same list-display logic selected by vendor and by material respectively, and are worth comparing side by side to see how much of ME3N's behavior is shared across the report family rather than specific to it. MK03 is useful for confirming which vendor master record is actually being selected against when results look incomplete. MIR4 is a natural next stop once an open PO in ME3N turns out to have an invoice-verification discrepancy rather than a delivery one.