Four ways to get open PO data out of SAP, ranked

OData, a read-only database user, a scheduled extract or driving SAP GUI. What each costs, what each survives, and which one your IT team will actually approve.

Every procurement reporting project turns on one question that has nothing to do with procurement: how does the data get out of SAP. Get this wrong and the project either never passes review or breaks quietly six months later.

There are four doors. They are not equally good, and it is worth being honest about which is which.

1. OData or REST service — first preference

A published service reading purchase order, confirmation and delivery data. Stable, documented, versioned, and it survives upgrades because that is what an interface contract is for.

• Needs a Basis or integration team to expose or activate the service
• Authorisation is explicit and auditable — a service user with display authorisation on the relevant objects
• Costs the most to set up and the least to own, which is the right way round

If you can have this, take it and stop reading. Everything below is a compromise.

2. Read-only database view — fast and complete

A user with select-only rights on the purchasing tables. Nothing is faster and nothing gives you more, because you are reading what SAP reads.

EKKO    header      vendor, doc date, purchasing org
EKPO    item        material, plant, qty, price, confirmation control key
EKET    schedule    delivery dates and scheduled quantities
EKES    confirm     vendor confirmations, by category
EKBE    history     goods receipts and invoice history

• Needs a DBA conversation and a user that genuinely cannot write
• You now own the joins, including the ones that are not obvious — deletion indicators, item categories, schedule line splits
• It bypasses SAP's own authorisation layer, which is the objection your security team will raise, and they are right to

3. Scheduled extract to a file share — unglamorous, very reliable

A background job runs an existing report on a schedule and drops a file somewhere. ME2N or a custom program, spooled out as CSV or Excel.

This is the option people are slightly embarrassed to propose, and it is frequently the correct one. It needs no new interface, no new database user, and no new authorisation concept — the report already exists and someone already has rights to run it.

• Latency is whatever the schedule is, which for a daily PO check is fine
• It breaks visibly — the file is missing or old — rather than silently
• Column layouts drift when someone edits the variant, so pin the variant and validate the header row on every run

4. Driving SAP GUI — the fallback, never the plan

Login, transaction, variant, execute, export, all driven by a bot. It works. It is also the only option on this list that a user interface change can break, and vendors change user interfaces.

Use it when a vendor offers nothing else and the work is worth doing anyway — with a user your IT team creates for it, and only after they confirm your SAP licence allows it. Do not build a five-year process on it, and do not let anyone describe it as an integration.

Validate before you calculate

Whichever door you use, the data arrives imperfect. A rules engine applied to a blank vendor field produces a confident wrong answer, and a confident wrong answer costs more credibility than no answer at all.

• PO number present and well formed
• Vendor present
• Plant present
• PO date valid
• Delivery date valid and not absurd
• Confirmation status available for the line
• Inbound delivery field readable, even when empty
• No duplicate PO line in the extract

Rows that fail belong in a data quality report with the reason attached — not silently dropped, and not silently flagged as exceptions. Those two failure modes are how reporting projects lose the room.

Read-only is a feature, not a limitation

Start from the position that nothing is ever written back to SAP. It removes the hardest objection in the security review, it makes the blast radius of a bug zero, and for PO and ASN tracking you lose nothing — every action the process produces is an email to a human, not a transaction.