Getting SAP data into Databricks has traditionally been a headache. Teams write custom extracts, stage files, and wait for a pipeline to finish before the data science work can even start.

There is a faster way. With the DVW Flow Tool you call SAP directly from a Databricks notebook and land your data into a table in minutes. This short demo shows how it works, from an empty flow to a clean table ready for forecasting and trend analysis.

Also available on YouTube.

Build the Flow With Drag and Drop

You start by clicking the Create Flow button. From there, simple drag and drop tools let you pull data from any type of SAP object. There is no script to write and nothing to hand off to a developer. You lay out the flow visually, connect the pieces, and you are ready to pull data.

Pull Sales History Straight From an SAP ECC Transaction Code

In the demo we pull sales history for forecasting and trend analysis. Rather than build the extract from scratch, you can call an existing SAP ECC transaction code that already returns the data you need. There is no need to reinvent the wheel.

The flow runs using your existing SAP authorizations, so nothing changes from a security or governance perspective. You see exactly the data you are already entitled to see in SAP, delivered straight into your Databricks notebook.

Header Rows Detected Automatically

Before the data lands, the preview shows you what it will look like. Built-in intelligence identifies the header rows for you, so you do not spend hours cleaning and reshaping the output before it is usable. The data arrives in a structured table, ready for the next step.

Why This Matters

The value here is speed and simplicity. Analysts and data scientists get SAP data into Databricks without waiting on a separate extraction process, and without learning the underlying SAP objects. The flow reads from the source, applies the same logic every time, and delivers a clean table in minutes.

And because the Flow Tool reads and writes SAP data, the same approach that lands data in Databricks can also push results back into SAP when you need to close the loop.

Ready to Try It?

The video above walks through the full flow from start to finish. If you would like to see how the DVW Flow Tool handles your specific SAP environment, we are happy to run a personalized demo.

The DVW Flow Tool is available as a 30 day free trial with full functionality and no commitment.

SAP now shares data with Snowflake and Databricks with no copy. It is a real step forward, and it has generated plenty of excitement. But getting SAP data into your platform is the easy half.

For AI, success is determined by what the model is fed. This post looks at what zero-copy sharing solves, what it does not, and how to stay in control of the SAP data your analytics and AI actually use.

The news is real

SAP now shares data with both Snowflake and Databricks using zero-copy. Databricks went live first, in late 2025, and Snowflake followed in 2026. In each case the data stays in SAP, and your platform reads it in place. There is no pipeline to build for that read, and no second copy to govern.

If you run a recent SAP cloud edition and you want trusted SAP figures inside Snowflake or Databricks for reporting, or to ground an AI model on real business data, this is a clean way to do it. We are glad to see it. Making SAP data easier to read into these two platforms is good for our customers.

What the headline leaves out

"No copy" and "no ETL" are true for one thing: the read. They do not mean the work is done.

• The share into your platform is read only. You can query it. You cannot change it.
• Any transformation is still yours to build. Zero-copy gives your AI access to the data. It does not clean it, join it, or shape it the way a model needs. Your team builds that in Snowflake or Databricks.
• To keep a prepared result, you write it into your own table. That is a copy. The moment you do real work, the copy you were told you had avoided comes back.
• It does not write into your core SAP systems. Data can be shared back to SAP's data cloud, but not into the SAP applications your business runs on.
• There is no zero-copy share into Alteryx, KNIME, Dataiku, Power BI, Excel, or the other tools most analysts work in every day.

None of this is a fault. It is just the limit of what the feature is built to do.

For AI, the question is control

A model is only as good as what it is fed. This is where the choice matters.

A live share hands your AI whatever sits in the view. A curated workflow puts a step you control between SAP and the model. Your team builds that step in Alteryx, KNIME, Dataiku, or the DVW Flow Tool. In it you:

• Choose the exact fields and rows the model sees, and nothing more.
• Mask sensitive data, check it, and apply your own business rules before it reaches the model.
• Save a dated, repeatable dataset, so you can show exactly what the model saw when it made a decision.

For a bank, an auditor, or any regulated team, this is what matters most. It is the difference between hoping your AI was trained on the right data and being able to prove it.

Who runs it, and how fast

Getting SAP data into Snowflake or Databricks with zero-copy is usually an IT-led program. SAP data has to be modeled into data products, the platforms are connected with admin rights, and the transformation is built by engineers. The business waits on IT to deliver it.

DVW is often run by the business. Once SAP access is granted, an analyst installs the connector in the tool they already use and can be building useful workflows in days, not weeks or months. They keep control of it, and they change it themselves as new questions come up, without raising a ticket every time.

You do not have to choose

It helps to be clear about scope. Teams do four things with SAP data. They analyze it, they migrate it, they automate the work around it, and they feed it to AI. Zero-copy helps with one slice of the first and the last: reading SAP data into Snowflake or Databricks for reporting and for grounding a model. It does not migrate SAP data. It does not automate SAP tasks. It does not write results back into your core SAP systems. Those needs do not disappear because one read got easier.

DVW covers all four. Self-service analytics into Alteryx, KNIME, Dataiku, Power BI and more, which is what most customers use DVW for every day. SAP data migration, including SAP ECC to SAP S/4HANA. Process automation across SAP GUI and Fiori. And AI pipelines that prepare SAP data and write the results back.

So this is not SAP or DVW. For governed, read only SAP data in Snowflake or Databricks, zero-copy is a good fit. For everything else your teams do with SAP data, DVW is built for it, and many customers will use both. Whatever SAP data platform you adopt, DVW is the bridge that makes SAP data usable in both directions, in the tools your teams already work in.

Office of Finance starter pack, part 6

If you work with SAP receivables data and you use KNIME, here is how to pull your customer line items straight into a workflow, clean them up and explore them, without exporting files or waiting on a separate SAP development.

In the demo recording you will see the whole workflow on one screen. It runs FBL5N, the customer line item display, so your receivables data lands in KNIME with SAP's own logic already applied, on the SAP authorizations you already have. No custom code, nothing new for IT to develop.

From there you explore balances by customer in an interactive dashboard, click a customer to filter the postings, and write the same data out to Excel for anyone who still wants a spreadsheet.

Try It on Your Own SAP System

This exact workflow is on the KNIME Community Hub, so you can download it and try it on your own SAP system. Get in touch and we will set you up with a trial.

Office of Finance starter pack for KNIME

Six short demos that read and write SAP finance data straight from KNIME with the DVW KNIME Connector for SAP. The full series:

1. Post journal entries to SAP
2. Explore SAP financial documents (FB03)
3. Explore the SAP general ledger (FBL3N)
4. Read the GL tables BKPF and BSEG
5. Explore cost center actuals (KSB1)
6. Explore customer line items (FBL5N) (this post)

Office of Finance starter pack, part 4

If you need SAP finance data straight from the source tables and you use KNIME, here is how to read the general ledger tables BKPF and BSEG into a workflow, filter them dynamically, and join them into one data set, without exporting entire tables or waiting on a separate SAP development.

In the demo recording you will see two table nodes read straight from SAP, the header table BKPF and the line item table BSEG, with an external list driving the filtering. It runs on the SAP authorizations you already have, with no custom code and nothing new for IT to develop.

The part worth watching: rather than pull all of BSEG, one of the largest tables in SAP, the workflow uses the document keys from BKPF to read only the matching line items, then joins the two into one table you can explore in KNIME or send to Excel.

Try It on Your Own SAP System

This exact workflow is on the KNIME Community Hub, so you can download it and try it on your own SAP system. Get in touch and we will set you up with a trial.

Office of Finance starter pack for KNIME

Six short demos that read and write SAP finance data straight from KNIME with the DVW KNIME Connector for SAP. The full series:

1. Post journal entries to SAP
2. Explore SAP financial documents (FB03)
3. Explore the SAP general ledger (FBL3N)
4. Read the GL tables BKPF and BSEG (this post)
5. Explore cost center actuals (KSB1)
6. Explore customer line items (FBL5N)

Office of Finance starter pack, part 5

If you work with SAP controlling data and you use KNIME, here is how to pull your cost center actual line items straight into a workflow, clean them up and explore them, without exporting files or waiting on a separate SAP development.

In the demo recording you will see the whole workflow on one screen. It runs KSB1, the cost center actual line items report, so the data lands in KNIME with SAP's own logic already applied, on the SAP authorizations you already have. No custom code, nothing new for IT to develop.

From there you explore balances by cost center in an interactive dashboard, click a cost center to filter the postings, and write the same data out to Excel for anyone who still wants a spreadsheet.

Try It on Your Own SAP System

This exact workflow is on the KNIME Community Hub, so you can download it and try it on your own SAP system. Get in touch and we will set you up with a trial.

Office of Finance starter pack for KNIME

Six short demos that read and write SAP finance data straight from KNIME with the DVW KNIME Connector for SAP. The full series:

1. Post journal entries to SAP
2. Explore SAP financial documents (FB03)
3. Explore the SAP general ledger (FBL3N)
4. Read the GL tables BKPF and BSEG
5. Explore cost center actuals (KSB1) (this post)
6. Explore customer line items (FBL5N)

Office of Finance starter pack, part 3

If you work with SAP finance data and you use KNIME, here is how to pull your general ledger straight into a workflow, clean it up and explore it, without exporting files or waiting on a separate SAP development.

In the demo recording you will see the whole workflow on one screen. It runs FBL3N, the general ledger line item display, so the data lands in KNIME with SAP's own logic already applied, on the SAP authorizations you already have. No custom code, nothing new for IT to develop.

From there you explore balances by G/L account in an interactive dashboard, click an account to filter the postings, and write the same data out to Excel for anyone who still wants a spreadsheet.

Try It on Your Own SAP System

This exact workflow is on the KNIME Community Hub, so you can download it and try it on your own SAP system. Get in touch and we will set you up with a trial.

Office of Finance starter pack for KNIME

Six short demos that read and write SAP finance data straight from KNIME with the DVW KNIME Connector for SAP. The full series:

1. Post journal entries to SAP
2. Explore SAP financial documents (FB03)
3. Explore the SAP general ledger (FBL3N) (this post)
4. Read the GL tables BKPF and BSEG
5. Explore cost center actuals (KSB1)
6. Explore customer line items (FBL5N)

Office of Finance starter pack, part 1

Most SAP connectors only read. The DVW KNIME Connector for SAP writes back, too. In this short demo we post journal entries straight into SAP from KNIME and get SAP's own confirmation back, without leaving the workflow.

Reading SAP data into an analytics platform is well understood. Writing it back is the part most tools cannot do. This workflow in this demo does both. It takes the documents you want to post, the header and the line items, the debits and the credits, from a simple set of inputs, with multiple documents in one workbook.

It then posts them into SAP as real journal entries. This is the programmatic equivalent of posting G/L documents in FB50, but driven from KNIME. The connector posts through a standard SAP BAPI, on the same authorizations a user would have. There is no custom app and nothing new for IT to build.

SAP posts the document and hands back its own response. The workflow splits that into successes and failures, so you see the new SAP document number for everything that posted and a clear reason for anything that did not. That is a full audit trail in KNIME, and the full response writes out to Excel so there is a record of exactly what was posted.

All of it runs through the SAP application layer, using permissions your users already have. Nothing touches the SAP database directly. Run it in the KNIME Analytics Platform, or on the KNIME Hub if you want to schedule it.

Try It on Your Own SAP System

This exact workflow is on the KNIME Community Hub, so you can download it and post to your own SAP system. Get in touch and we will set you up with a trial.

Office of Finance starter pack for KNIME

Six short demos that read and write SAP finance data straight from KNIME with the DVW KNIME Connector for SAP. The full series:

1. Post journal entries to SAP (this post)
2. Explore SAP financial documents (FB03)
3. Explore the SAP general ledger (FBL3N)
4. Read the GL tables BKPF and BSEG
5. Explore cost center actuals (KSB1)
6. Explore customer line items (FBL5N)

Office of Finance starter pack, part 2

If you work with SAP finance data and you use KNIME, here is how to pull a list of your posted financial documents straight into a workflow and explore it, without exporting files or waiting on a separate SAP development.

In the demo recording you will see that the whole workflow sits on one screen. The first node uses an SAP transaction your finance team already knows, FB03, the document list search. You apply filters for just the data that is relevant to you. Because it runs the transaction, the data comes out with SAP's own logic already applied. You are not rebuilding it from raw tables, and it runs on the SAP authorizations you already have. There is no custom code and nothing new for IT to develop.

Run the node and the documents land in KNIME as a table. Document number, company code and all the other fields you would expect, straight from SAP.

This is where KNIME earns its place. Open the view and you have an interactive dashboard. The documents are grouped on a chart, with a full list in the table, and they are linked. Click a bar and the table filters to just those documents. The same data writes out to Excel at the same time, for anyone downstream who still wants a spreadsheet.

Try It on Your Own SAP System

This exact workflow is on the KNIME Community Hub, so you can download it and try it on your own SAP system. Get in touch and we will set you up with a trial.

Office of Finance starter pack for KNIME

Six short demos that read and write SAP finance data straight from KNIME with the DVW KNIME Connector for SAP. The full series:

1. Post journal entries to SAP
2. Explore SAP financial documents (FB03) (this post)
3. Explore the SAP general ledger (FBL3N)
4. Read the GL tables BKPF and BSEG
5. Explore cost center actuals (KSB1)
6. Explore customer line items (FBL5N)

SAP has set a deadline that is reshaping the plans of tens of thousands of large organizations. Mainstream support for SAP ECC, the ERP that has run finance, supply chain and operations for many of the world's biggest companies for the better part of two decades, is coming to an end.

This is a short, plain-English guide to what that actually means, the real dates, why SAP is doing it, and what customers are doing about it, whether they are migrating to S/4HANA or staying on ECC for years yet.

What SAP ECC is

SAP ECC (ERP Central Component, part of SAP Business Suite 7) is the on-premise ERP that runs finance, supply chain, manufacturing, procurement and HR for a large share of the world's biggest companies. When someone says "we run SAP," they usually mean ECC. It is the system of record, heavily customized over many years, and deeply tied to how the business operates day to day.

S/4HANA is SAP's next-generation replacement. It runs on SAP's in-memory HANA database, has a simpler data model and a modern interface, and it is where SAP is putting its investment. Customers can run it on-premise, in a private cloud, or in a public cloud edition.

The move from ECC to S/4HANA is not a routine upgrade. In most cases it is a full re-implementation, and it typically runs as a 12 to 24 month program that touches data, custom code, integrations and business processes all at once.

The deadline, and what it actually means

SAP has put a firm clock on ECC to encourage the move:

• End of 2027 is the headline date. Mainstream maintenance for ECC 6.0 on the current Enhancement Pack levels (6 to 8) ends on 31 December 2027. That is full support: fixes, security patches, and legal and regulatory updates.
• Customers on older Enhancement Packs (1 to 5) are already out of mainstream maintenance, as of the end of 2025.
• Optional extended maintenance runs to end of 2030. It costs roughly two percentage points more on the annual maintenance fee, around a 9% increase, and buys three more years.
• After that, customers move to "customer-specific maintenance," which in practice means no new fixes or updates. The system is effectively unsupported.
• S/4HANA, the destination, is committed for support until at least 2040.

One point is widely misunderstood, so it is worth being clear about it. End of support does not mean ECC stops working on 1 January 2028. The software keeps running. What stops is SAP fixing problems, issuing patches, and shipping the legal and tax updates that finance and compliance teams depend on. For regulated businesses, that is the real exposure, not the system going dark.

Why SAP is doing this

The deadline is a commercial lever as much as a technical one. SAP wants to move its installed base onto S/4HANA, and increasingly into the cloud through its RISE with SAP program, for a few connected reasons:

• It shifts customers from one-off perpetual licenses to recurring cloud subscriptions.
• A single modern platform is far cheaper for SAP to maintain and improve than a long tail of heavily customized ECC systems.
• SAP's newer story, built around its cloud data platform and embedded AI, is designed for S/4HANA rather than ECC. The deadline pulls customers toward where SAP intends to sell next.

The scale of the ECC base and the depth of customization make this one of the largest forced-modernization events the enterprise software market has seen.

How many customers are actually delaying, and why

The migration is genuinely underway. By late 2025, around 59% of surveyed SAP customers were fully or partially live on S/4HANA, up 13 points on the year before. The momentum is real, particularly among the largest enterprises.

At the same time, close to half the installed base is not moving on SAP's timetable. At the end of 2024, only about 39% of ECC customers, roughly 14,000 out of 35,000, had migrated. Gartner projects that around 17,000 customers, close to half the base, will still be running ECC when the 2027 deadline arrives. IDC puts the figure at 40 to 45% of ECC users remaining on the older system through 2027.

The reason is straightforward. For many organizations the business case does not yet stack up. In one 2025 survey, 95% said building a positive return-on-investment case for S/4HANA is difficult or takes significant effort, and nine in ten were worried about rising and unpredictable subscription costs. Nearly a quarter said they plan to stay on on-premise ECC. The barriers most often cited come down to the cost and disruption of the move itself: complex customizations built up over many years, and migration programs that can run from a few million dollars into the hundreds of millions. ECC still runs the company, so for a lot of boards the migration looks like cost and risk now in exchange for benefits that are hard to quantify, and it slips behind work that earns revenue.

A growing group has gone further and chosen a "composable" approach on purpose: keep ECC as the core, add analytics and automation around it, and buy time without committing to a full re-implementation.

The options if you are not ready

If a customer cannot or will not migrate by 2027, paying SAP more is not the only choice. There are three broad routes, and they are increasingly weighed together.

Pay SAP for extended maintenance to 2030. The simplest option. It costs roughly two percentage points more on the maintenance bill and pushes the cliff edge out to the end of 2030. It is a premium for the same support, and the clock still runs out.

Move to third-party support. Independent providers take over support of the existing ECC system in place of SAP, typically for around half the current SAP maintenance fee, often on three-year contracts. For a large estate that can mean savings of several million a year. The established providers are Rimini Street, which is the largest and supports thousands of clients including many Fortune 500s, and Spinnaker Support, which positions itself as a higher-touch alternative with dedicated engineers and a strong reputation on complex ECC environments. Smaller and regional firms such as Support Revolution serve specific markets. The trade-off is that you step off SAP's roadmap and rely on the third party rather than SAP for fixes and updates, and the commercial relationship with SAP can become more difficult. Customers who take this route have usually decided to delay or skip S/4HANA, which makes them a multi-year ECC population.

Stay on ECC unsupported. The cheapest path on paper and the riskiest in practice, given the security and compliance exposure. It is rarely a deliberate strategy for a large regulated business, but it happens by drift.

Where DVW helps, whichever path you take

Everything above explains a question customers keep asking: how do we keep getting value out of SAP while the migration question hangs over us? You do not have to wait for the S/4HANA project to answer it. DVW helps the customers who are staying on ECC and the customers who are moving to S/4HANA, and for a simple reason: the same connection works against both.

DVW Analytics builds the connectors that let an analytics or automation platform read from and write to SAP directly. The promise is plain: read and write SAP data from any analytics or data platform. Two things make that matter here. First, reading and writing together: plenty of tools can pull data out of SAP for reporting, far fewer can write validated data back into it, and most of the work below needs both directions. Second, the same connection runs against ECC and S/4HANA alike, including private cloud and RISE, so nothing you build on ECC today is thrown away when you eventually move.

If you are staying on ECC

For the large group that will sit on ECC for years yet, the practical question is how to keep improving now rather than waiting on a timeline you do not control. This is the "composable" approach in action: keep ECC as the core, and put modern analytics and automation around it.

That matters most where end of support bites first. ECC keeps running after 2027, but SAP stops shipping the legal and tax updates that finance, tax and audit teams rely on. DVW does not replace those updates, but it gives those teams a way to compensate: stronger reporting, tighter reconciliation, and automated controls built directly on live SAP data, so issues are caught and evidenced rather than missed. The same connectors also automate manual SAP work and reduce the reliance on scarce SAP specialists. For customers who have moved to third-party support and freed up budget in the process, this is a direct way to put some of that saving to work.

If you are migrating to S/4HANA

For customers who are moving, the hardest part is rarely the software, it is the data. DVW covers the data work phase by phase:

• Profiling ECC data before the move: volumes, quality, and coverage
• Finding and fixing poor master data: duplicates, address gaps, stale records
• Mapping ECC codes and structures to their S/4HANA equivalents
• Running trial loads into a sandbox and capturing what fails
• Reconciling source against target across every data domain
• Running ECC and S/4HANA in parallel during a phased cutover, keeping the two in step

Because the same connection works on both systems, the profiling, controls and automation you build before the move carry straight over to S/4HANA afterwards. The work earns its keep twice. For the full breakdown of how DVW handles each phase, see our SAP data migration page.

One connector for your platform

Whichever path you are on, DVW meets you in the platform your team already uses, plus a standalone option if you would rather run SAP integration on its own:

• DVW Alteryx Connector for SAP plugs straight into Alteryx and moves data both ways between SAP and an Alteryx workflow.
• DVW KNIME Connectors for SAP do the same inside KNIME.
• DVW Dataiku Connector for SAP brings SAP data into the Dataiku platform for analysis and modeling.
• DVW Flow Tool is DVW's own standalone option, reading and writing SAP data and running automated flows without needing one of the analytics platforms above.

Wherever you are on the journey to S/4HANA, and whether you are going at all, DVW is here to help you get more out of SAP in the meantime.

Sources

• SAP, maintenance strategy and S/4HANA innovation commitment to 2040: support.sap.com
• E3 Magazine, "Business Suite 7 maintenance until 2027/2030 and S/4HANA until 2040": e3mag.com
• UpperEdge, "SAP Extends Maintenance Options to 2030": upperedge.com
• CIO, "Nearly half of SAP ECC customers may stick with legacy ERP beyond 2027": cio.com
• CIO, "SAP customers not sold on S/4HANA ROI": cio.com
• Precisely, "New Research Reveals SAP S/4HANA Migration Momentum": precisely.com
• Computer Weekly, "SAP ECC customers bet on composable ERP to avoid upgrading": computerweekly.com
• SAP Licensing Experts, "Rimini Street vs Spinnaker Support vs SAP: Independent Maintenance Comparison 2026": saplicensingexperts.com
• Redress Compliance, "SAP Third-Party Support Compared: Rimini Street vs Spinnaker vs SAP": redresscompliance.com

In this blog we identify the most important SAP Warehouse Management (WM) and Extended Warehouse Management (EWM) tables for users of:

• Alteryx and the DVW Alteryx Connector for SAP
• KNIME and the DVW KNIME Connector for SAP
• Dataiku and the DVW Dataiku Connector for SAP
• Power BI, Tableau, Databricks, Snowflake and the DVW Flow Tool

SAP warehouse data lives in two parallel table sets. Classic WM (LTAK, LTAP, LQUA and their related tables) is still used in many SAP ECC and SAP S/4HANA landscapes. Extended Warehouse Management (EWM) sits in its own /SCWM/ namespace and is the strategic warehousing platform in SAP S/4HANA. Understanding which set applies to your site is essential for stock accuracy, pick productivity, slotting and dock-to-stock analytics.

SAP Warehouse Management tables are found in the following SAP systems:

• SAP ECC (classic WM)
• SAP ERP (classic WM)
• SAP S/4HANA (classic WM and embedded EWM)
• SAP decentralised EWM

The /SCWM/ tables exist only in SAP S/4HANA or decentralised EWM systems. The classic WM (L*) tables exist in both SAP ECC and SAP S/4HANA.

Classic Warehouse Management (WM) Tables

Classic WM uses the L* table family to record transfer orders, transfer requirements, bin-level stock and warehouse master data. These tables are available in both SAP ECC and SAP S/4HANA and remain the backbone of warehouse reporting for sites that have not yet migrated to EWM.

Transfer Order Tables

LTAK - Transfer Order Header. Contains one row per transfer order with fields such as warehouse number (LGNUM), transfer order number (TANUM) and movement type (BWLVS). The source storage type (VLTYP) and destination storage type (NLTYP) describe the physical movement. This is your starting point for all transfer order analysis including picking, putaway and replenishment.

LTAP - Transfer Order Item. Contains one row per line item within each transfer order. Key fields include warehouse number (LGNUM), transfer order number (TANUM), item number (TAPOS), material (MATNR), batch (CHARG), source storage type (VLTYP), destination storage type (NLTYP) and source quantity (VSOLM). Join to LTAK on LGNUM and TANUM to build a complete transfer order dataset.

LTBK - Transfer Requirement Header. Contains one row per transfer requirement with fields such as warehouse number (LGNUM) and transfer requirement number (TBNUM). Transfer requirements are the planned demand that triggers transfer orders, so this table is important for understanding backlog and open workload.

LTBP - Transfer Requirement Item. Contains one row per line item within each transfer requirement. Key fields are warehouse number (LGNUM), transfer requirement number (TBNUM) and item number (TBPOS). Join to LTBK on LGNUM and TBNUM for open demand reporting.

WM Stock Tables

LQUA - Quant / Stock in Bin. Contains one row per quant, which is the unit of stock of a given material in a specific bin. Key fields include warehouse number (LGNUM), quant number (LQNUM), material (MATNR), batch (CHARG), total quantity (GESME), available quantity (VERME), storage type (LGTYP) and storage bin (LGPLA). This is the primary table for bin-level stock reporting, slotting analysis and cycle count preparation.

LEIN - Storage Unit Header. Contains one row per storage unit with fields such as warehouse number (LGNUM), storage unit number (LENUM), storage unit type (LEART) and current bin (LGPLA). Use this table where storage unit management is active, for example on pallet-based operations.

WM Master Data Tables

LAGP - Storage Bins. Contains one row per storage bin with fields such as warehouse number (LGNUM), storage type (LGTYP) and bin coordinate (LGPLA). Join to LQUA on LGNUM, LGTYP and LGPLA to enrich stock data with bin attributes such as section, picking area and bin type.

Extended Warehouse Management (EWM) Tables

EWM tables live in the /SCWM/ namespace and are only present in SAP S/4HANA (embedded EWM) or decentralized EWM systems. The object model is richer than classic WM, with warehouse tasks, handling units and delivery order documents replacing transfer orders and deliveries.

EWM Warehouse Task Tables

/SCWM/ORDIM_O - Open Warehouse Task. Contains one row per open task line with key fields task number (TANUM) and task item (TAPOS). Use this table to measure open pick, putaway and replenishment workload in real time.

/SCWM/ORDIM_C - Confirmed Warehouse Task. Contains one row per confirmed task line with key fields task number (TANUM) and task item (TAPOS). This is the historical record of completed work and is the starting point for productivity, travel time and dock-to-stock analytics.

EWM Stock and HU Tables

/SCWM/HUHDR - Handling Unit Header. Contains one row per handling unit with key field GUID_HU. The external handling unit number (HUIDENT) is the readable identifier used on labels and scanning devices. Essential for any pallet or tote-level reporting.

/SCWM/QUAN - EWM Quants / Stock. Contains one row per quant of stock in EWM. Key fields include warehouse number (LGNUM), stock category (CAT), stock type (STOCK_TYPE) and owner (OWNER). The record carries material identifier (MATID), external handling unit number (HUIDENT) and quantity (QUAN). This is the primary table for EWM stock reporting.

/SCWM/LAGP - EWM Storage Bins. Contains one row per EWM bin with key fields warehouse number (LGNUM) and bin (LGPLA). Join to /SCWM/QUAN to enrich stock data with EWM bin attributes.

EWM Delivery Tables

/SCDL/DB_PROCH_O - EWM Outbound Delivery Order Header. Contains one row per outbound delivery order header with key field DOCID (items in /SCDL/DB_PROCI_O). This is the EWM equivalent of the ERP outbound delivery and is the starting point for outbound flow analytics in EWM sites.

/SCDL/DB_PROCH_I - EWM Inbound Delivery Header. Contains one row per inbound delivery header with key field DOCID (items in /SCDL/DB_PROCI_I). Use this table for goods receipt, putaway lead time and supplier on-time analytics in EWM.

Material Document Tables

Material documents record every inventory movement in SAP and are the reconciliation point between warehouse transactions and inventory accounting. They apply to both classic WM and EWM sites.

MKPF - Material Document Header. Contains one row per material document with key fields document number (MBLNR) and document year (MJAHR). Use this as the header for all goods movement reporting in SAP ECC.

MSEG - Material Document Items. Contains one row per material document line item with key fields document number (MBLNR), document year (MJAHR) and item number (ZEILE). Join to MKPF on MBLNR and MJAHR for complete movement-level reporting.

MATDOC - Universal Material Document (SAP S/4HANA). In SAP S/4HANA, MATDOC replaces MKPF and MSEG as the single source of truth for material movements. Key fields are document number (MBLNR), document year (MJAHR) and item number (ZEILE). SAP also exposes compatibility views named MKPF and MSEG on top of MATDOC, so legacy queries continue to work, but new S/4HANA analytics workflows should target MATDOC directly for performance and to access the extended field set.

Material Master Tables

Material master data is spread across several tables in SAP, each holding a different slice of the material record. Together they provide the dimensional context for warehouse and stock reporting.

MARA - Material Master: General Data. Contains client-level material data with key field material number (MATNR). Typical fields include material type, material group and base unit of measure. This is your primary material dimension table.

MARC - Material Plant Data. Contains material data specific to a plant with key fields material number (MATNR) and plant (WERKS). Includes fields such as MRP controller, procurement type and ABC indicator. Join to MARA on MATNR.

MARD - Storage Location Stock. Contains stock quantities per material, plant and storage location with key fields material number (MATNR), plant (WERKS) and storage location (LGORT). Key stock fields are unrestricted use stock (LABST), quality inspection stock (INSME) and blocked stock (SPEME). MARD is the aggregate counterpart to the bin-level stock held in LQUA and /SCWM/QUAN.

MCHA - Batches per Plant. Contains one row per batch at a plant with key fields material number (MATNR), plant (WERKS) and batch (CHARG). Important wherever batch management is active, for example pharmaceuticals, food and chemicals.

WM Configuration Tables

Configuration tables (also known as customizing tables) define the plants, storage locations and warehouses in your system and how they are connected. These tables are small and slowly changing, and they are essential for decoding the values in transaction and master data tables. The configuration tables listed below apply to both SAP ECC and SAP S/4HANA.

T001L - Storage Locations. Contains one row per storage location with key fields plant (WERKS) and storage location (LGORT). Join to MARD to decode storage location codes in stock reports.

T001W - Plants. Contains one row per plant with key field plant (WERKS). Useful for filtering and grouping data by plant in multi-site warehouse reports.

T300 - WM Warehouse Numbers. Contains one row per classic WM warehouse number with key field warehouse number (LGNUM) and linked plant (WERKS). Use this table to translate warehouse numbers into readable site labels.

T320 - Storage Location / Warehouse Assignment. Contains one row per link between a storage location and a WM warehouse number, with key fields plant (WERKS), storage location (LGORT) and warehouse number (LGNUM). This is the bridge between MM storage location stock (MARD) and WM bin-level stock (LQUA).

Explore SAP WM and EWM Tables with a DVW Connector

The fastest way to explore SAP WM and EWM tables is to connect directly to your SAP system from your preferred analytics platform. DVW Connectors let you browse available tables, preview fields and extract data without writing any ABAP code. All DVW products support classic WM and EWM across SAP ECC and SAP S/4HANA.

To see how all 25 tables in this blog connect to each other, visit our SAP WM / EWM Table Relationships page for an interactive data model diagram with join keys and ECC vs S/4HANA compatibility.

All DVW products include a 30-day free trial with full functionality, so you can start working with these tables right away. Visit our Free Trial page to get started, or explore our Help Centre for detailed documentation on connecting to SAP WM and EWM tables.

Next Steps

See these SAP WM and EWM tables in action. Register for a 30-day free trial and start extracting warehouse, transfer order and stock data from your SAP system today.