You only share what matters.

Most platforms extract everything and let you figure out relevance later. That's wasteful, slow, and whether you're feeding a data lake, training an AI model, or sharing data with a partner — it's a problem.

OneScope takes a different approach. Before a single record leaves your SAP system, the precise dataset is determined. Only the fields you need. Only the records that qualify. Only the related data that belongs. Internal analytics, cross-department reporting, AI workloads, B2B data sharing — same mechanism, same precision.

Scoped to what matters. Aligned across every table.

Three layers of control. One cohesive result.

Field Selection
The extraction profile specifies exactly which columns to extract. A table with 300 fields — take the 12 you need. Reduces data volume and minimizes exposure at the column level. For internal extractions, your team defines the boundary. For B2B data products, the ISV sets it and customers cannot expand beyond the product definition.
Record Filtering
Define the criteria that determine which records qualify. Filters run inside SAP — records that don't match never leave. Company code, sales office, date range, plant — whatever your use case requires. For internal extractions, you set the filters directly. For B2B products, customers apply their own filters within the ISV's defined boundary.
Scope Relationships
Related objects are automatically scoped based on parent-child key relationships. When a parent object is filtered to specific criteria, child objects are constrained to only records belonging to qualifying parents. The dataset is relationally complete by design.

Open sales order visibility.

Your sales team needs a complete open order book — headers, line items, schedule lines, and the relevant master data — scoped to specific parts of the business. Maybe it feeds a dashboard. Maybe it feeds an AI model. Maybe it's a data product an ISV built for you. The scoping works the same way regardless.

The extraction profile defines the data universe: VBAK (sales order headers), VBUK (header status), VBUP (item status), VBAP (line items), VBEP (schedule lines), KNA1 (customer master), MARA (material master), MVKE (material sales data) — and whatever additional master data the use case requires. Tables, fields, relationships. That's the blueprint.

Starting with VBAK filters out quotes, contracts, bids, and every other SD document type. VBUK determines which orders are open at the header level. VBUP determines which line items are open. A sales order closed short with open lines? Those lines never appear — by design. The scope cascades: only open headers, only open line items on those headers, only schedule lines on those items.

Then it goes further. MARA and MVKE are included — but only the material master records for materials that appear on the open orders. Not 500,000 materials. Just the ones that matter right now. Customer master follows the same pattern — KNA1 on ECC, Business Partner on S/4HANA — scoped to only the customers with open orders. Need sales area data from KNVV? Company code data from KNB1? Add them to the scope. Only the records belonging to qualifying customers come through.

The SAP customer narrows it to their business. One sales office to start. One company code. OneScope computes the entire dataset inside their SAP system.

Run as a full rebuild on a schedule — every 15 minutes — and the destination database is a clean open order book every time. Nothing stale. Nothing closed. Just what's open right now, with the master data to make it useful.

The app developer doesn't build status logic. Doesn't filter closed orders. Doesn't join master data. The data layer did it. The app just reads the table.

58,800 orders in. 3,389 rows out. Four domains. Three passes.

A real extraction scope computed inside a live SAP system. Four business domains wired through OneScope — forward, check, refine — until only relationally consistent data remains.

FORWARD PASS 58,800 Orders 542 Customers 688 Materials CHECK: TVKO BUKRS 3000 → only 2 sales orgs survive Config table not in the output drives the constraint CASCADE — WALK BACK UP 10,574 → 2,692 Orders (−75%) 542 → 290 Customers (−46%) REFINE — RE-EVALUATE ALL DOMAINS 2,692 Orders (held) 285 Customers (refined) 397 Materials (688 → 397) 3,389 rows
● Orders (VBAK, VBAP, VBEP, VBUK, VBUP) ● Customers (KNA1, KNB1, KNVV, KNVP) ● Materials (MARA, MVKE) ● Config check (TVKO)
Three passes. Four domains. A config table that isn't even in the output drove the constraint that shaped the entire dataset. Every domain re-evaluated after the cascade. Relationally consistent across all tables. Computed inside SAP before any data moved.

Every extraction use case benefits from precise scoping.

OneScope isn't just for B2B data sharing. Any time you extract SAP data — for any purpose — the same precision applies.

Analytics & Data Lake
Feed Snowflake, Databricks, or BigQuery with precisely scoped SAP data. Only the tables, fields, and records your analytics actually need.
AI & Machine Learning
Train models against relationally consistent SAP operational data. Scoped to the business context that matters — not the entire landscape.
Finance & Procurement
GR/IR reconciliation, AP aging, vendor analysis — scoped to specific company codes, plants, or date ranges. Continuously current.
Cross-Department Reporting
Supply chain, sales, manufacturing — each team gets their scoped view of SAP data without competing for Basis resources or report scheduling windows.

Add your own filters. One company code to start. A specific plant. A date range. OneScope runs inside your SAP environment and computes the scope against your data. Only scoped records are extracted. Want to expand later? Add another company code. Remove a filter. The scope adjusts.

Your filters. Your rules. Your data. Whether it feeds your own systems or a partner's.

Define once. Deploy everywhere.

For ISVs building data products on the marketplace, OneScope adds a critical layer: the ISV defines the data boundary, and customers scope within it. The ISV specifies tables, fields, and relationships. The customer applies their own filters — company code, plant, date range — but cannot expand beyond the product definition.

The question that blocks deals: "How much of our data do we have to share?"

With OneScope, the answer is: exactly what your application needs. Nothing more. Every customer. Every time.

OneScope is a performance feature, not just a governance feature.

By computing the precise scope inside SAP before extraction runs, the extraction engine doesn't process records that don't belong. Smaller files. Faster delivery. Less load on the SAP system during the extraction window.

Governance and performance. Same mechanism.

OneScope controls what leaves SAP. That's half the story.

Deciding which records and fields to share is precision. But a customer number that exists for joining shouldn't be readable. A name field that has no business leaving SAP shouldn't leave at all. And when two companies need to correlate data on a shared key — neither should see the other's raw value.

That's the other half. Field-level protection, applied per column, enforced before data leaves your SAP system.

Explore Data Protection →

Precision changes what's possible.

OneScope is one of several capabilities that make DataXover the only native SAP extraction platform.