ERPClimb logoERPClimb
SAP transaction codeObjectLBWEModuleBW_ANALYTICS

LBWE — LO Data Extraction Customizing Cockpit

LBWE is the Logistics (LO) Data Extraction Customizing Cockpit, used to activate, deactivate and configure the extract structures behind the 2LIS_* DataSources (sales, purchasing, inventory, shop floor, etc). It controls which fields are extracted, which update mode feeds the delta queue, and it is the only place LO extract structures can legitimately be changed, not RSA6 or RSA5.

This page covers the LBWE cockpit used to build and activate LO extract structures for 2LIS_* DataSources, how the update mode choice determines delta behaviour, and the recurring diagnostic patterns around setup tables, queue backlogs and structure changes made after go-live. It also covers ownership and what changed under S/4HANA.

Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,286 words

Purpose

LBWE is the customizing transaction for the LO (Logistics) extraction structures that feed the 2LIS_02 (purchasing), 2LIS_03 (inventory), 2LIS_11 (sales), 2LIS_04 (shop floor) and related DataSources. It lets a consultant select which fields from the standard communication structure get carried into the extract structure, activate or deactivate that structure, and choose the update mode that determines how delta records reach the delta queue. The structural fact that explains most confusion: activating or changing an extract structure here regenerates the extractor's underlying function modules and control tables, and anything already sitting in the setup tables or the delta queue at that point is not automatically reconciled. LBWE is customizing, not extraction execution; the actual data movement happens through the update task, the extraction queue and the delta queue, none of which LBWE displays directly.

When it is used

A consultant opens LBWE during the initial setup of a LO cockpit DataSource, before the first delta init, to decide which fields are needed and which update mode to run. It is also opened whenever a business requirement needs a field added to an extract structure that is not in the standard set, or when a delta suddenly stops moving and the update mode or activation status needs to be confirmed. It is not the place to check whether data has actually arrived in BW, that is RSA3 for extraction checks or RSA7 for the delta queue content. It is also not used for generic (non-LO) DataSources, those are built and extended through RSA6 and the generic extraction customizing, a distinction that trips up people coming from a pure BW background.

How to use it in practice

  • Open LBWE and select the application area (Logistics application, e.g. Sales and Distribution, Purchasing, Inventory Management).
  • Expand the DataSource node to see the current extract structure and its activation status.
  • If adding fields, go into the maintenance of the extract structure, add fields from the communication structure or an append, and save; this triggers structure regeneration.
  • Set or confirm the update mode against the DataSource: direct delta, queued delta, or unserialized V3 (serialized V3 is legacy and should not be chosen on a new build).
  • Activate the DataSource/extract structure from within LBWE; this is the LO-specific activation step, distinct from RSA6.
  • If the extract structure changed on a live delta, deactivate first, make the change, reactivate, then re-run the statistical setup for the affected application and reconcile with the delta queue before resuming delta loads.

Key data objects

  • Extract structure (generated per application, e.g. an MC-prefixed structure for the relevant application) - holds the fields selected in LBWE that get passed to the DataSource.
  • Setup table (dynamically named per application, typically the extract structure name suffixed with SETUP) - holds the historical data produced by the statistical setup run, read during a full load.
  • LO cockpit control table for active extract structures and update mode - records which structures are active and which delta mode (direct, queued, V3) is assigned; this is what LBWE is actually writing to on save.
  • Extraction queue (LBWQ) - populated when queued delta is selected; records wait here until the update collector job moves them.
  • Delta queue (RSA7) - the final holding area for delta records regardless of update mode, read by the BW extraction request.

How to prove it in the data

To confirm which DataSources are active and in which update mode, open the relevant application node in LBWE directly rather than guessing from a table dump, since the control table names are generated per application and easy to misidentify. To confirm whether records are stuck rather than missing, check LBWQ for the DataSource's application and look for a growing queue with no recent processing timestamp, then check RSA7 for the same DataSource to see if anything has arrived at all. A queue full in LBWQ with nothing in RSA7 points at the collector job, not at LBWE configuration.

ECC vs S/4HANA

LBWE still exists and functions the same way on S/4HANA. Classic 2LIS_* extraction continues to work because S/4HANA provides compatibility views mapping the changed underlying application tables back to the structures the old extractors expect. There is no Fiori app replacing LBWE; it remains a SAPGUI-only transaction. New implementations on S/4HANA increasingly favour CDS-based extraction or ODP sourcing over classic LO cockpit extraction, but existing LO cockpit setups built through LBWE are not automatically migrated away and keep working until deliberately replaced.

Common pitfalls and how to diagnose them

  • Update mode mismatch: queued delta is selected in LBWE but the background job that moves the extraction queue into the delta queue is never scheduled or has stopped; symptom is LBWQ growing indefinitely while RSA7 stays empty. Check the job schedule before touching LBWE settings.
  • Structure changed on a live delta: a field is added to the extract structure while delta loads are already running, without deactivating first or without redoing the statistical setup afterward. Result is either the new field arriving as blank in historical records, or duplicate records once the setup table is refilled against a queue that already has overlapping data. The safe sequence is deactivate, change, reactivate, delete and refill setup table, then resume delta.
  • Wrong maintenance transaction used: someone edits hide/select flags or tries to extend the DataSource through RSA6 or RSA5 instead of LBWE. For LO cockpit DataSources this either has no effect or breaks the generated extractor logic on the next activation.
  • Serialized V3 still configured: an older configuration left on serialized V3 update causes sequencing problems under load, particularly for goods movement documents where posting order matters; this shows up as intermittent stock quantity discrepancies rather than outright load failures.
  • Reactivation during business hours: extract structure activation regenerates code used inside the update task; doing this while transactions are being posted against the affected application can interrupt those postings. Schedule structure changes for a low-activity window.
  • Setup table not cleared before a refill: rerunning the statistical setup without deleting the previous setup table content for the same selection produces duplicated records in the next full load, which then have to be corrected downstream rather than at source.

Whose problem this is

Functional consultant territory for field selection and update mode decisions, done jointly with the BW/data warehouse consultant who owns the downstream extraction and load. Basis owns the background job scheduling for delta collection and qRFC processing. A clean handover states the DataSource, the update mode chosen and why, whether a structure change requires a setup table refill, and confirmation that the relevant collector job is scheduled and running.

Related SAP objects

Reviewed pages this object connects to in the ERPClimb knowledge graph.

Source: ERPClimb — https://erpclimb.com/sap-tcodes/lbweERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.