SAP BW developer on retainer: ZGBU_WO_HIST aDSO semantic key missing LOGSYS field — 847 legacy ECC work orders overwritten by S/4HANA migration backload on October 3 DTP activation — SAP BW/4HANA developer on monthly retainer

SAP BW/4HANA 2.0 SP10 • aDSO semantic key • 0LOGSYS • DTP activation • S/4HANA migration • AUFNR collision • Plant Maintenance • BEx query • retainer billing

At Great Basin Utility Authority, a nightly Process Chain had been loading Plant Maintenance work order history into SAP BW/4HANA without incident since the system’s initial deployment in 2025 — over 1.28 million records from the legacy SAP ECC system loaded cleanly across dozens of nightly delta runs. Then, on the morning of October 4, 2026, maintenance supervisors noticed something wrong in the BEx query “Open Work Orders by Plant/Priority.” The query was showing 847 open, high-priority work orders that no one could locate in the field. The work orders referenced plant assignments in the wrong region, carried creation dates from 2013 through 2018, and had no corresponding entries in the S/4HANA operational system. The SAP BW developer retainer was called in the same morning. The DTP had completed with zero errors. The Process Chain had finished green. Nothing in the BW monitoring stack had flagged a problem.

Great Basin Utility Authority ran SAP BW/4HANA 2.0 SP10 on SAP HANA 2.0 SPS08, with BW system ID BW4P hosted on a single BW application server (bw4-app-01) backed by a dedicated HANA database server (hana-db-01). The Plant Maintenance subject area was served by a single write-optimized aDSO named ZGBU_WO_HIST (Work Order History), which held 1,284,723 records loaded from the legacy SAP ECC system using the full-load DataSource ZMAINT_WO_ECC. The September 2026 migration to SAP S/4HANA (system ID S4P) had added a second DataSource, ZMAINT_WO_S4, configured as a delta DataSource feeding the same aDSO via the delta DTP DTP_ZGBU_WO_DELTA. The delta DTP was scheduled nightly at 23:00 as part of Process Chain PC_PM_DAILY. The first delta runs after the S/4HANA go-live in late September had loaded new work orders correctly — AUFNRs 4001284724 and above, well outside the existing ECC range.

What no one had anticipated: a migration consultant had also backloaded 847 maintenance work orders from a third-party CMMS system into S/4HANA. These were historical records the utility wanted in the operational system for continuity. The S/4HANA basis team assigned them AUFNRs 4000004001 through 4000004847 — a range that looked like available low-number identifiers in the S/4HANA number range configuration, but fell squarely within the block of AUFNRs already held by the ECC legacy records in the BW aDSO. On October 3, these 847 records entered the S/4HANA delta queue and were picked up by the nightly DTP run. The aDSO activation run did exactly what it was designed to do: it compared each incoming AUFNR against the active table, found a match for all 847, and recorded them as updates. Eight hundred and forty-seven ECC work order records — all marked COMPLETED, from maintenance events between 2013 and 2018 — were silently replaced with S/4HANA CMMS data showing OPEN status, high priority, and incorrect plant assignments.

The SAP BW developer retainer spent 1.5 hours on diagnosis and 2.5 hours implementing the fix and coordinating the full reload. Validation with the maintenance operations team took another 1.5 hours. Total engagement: 5.5 hours. The root cause was a single missing InfoObject in the aDSO semantic key: 0LOGSYS (Logical System), the standard SAP BW mechanism for distinguishing records from different source systems loading into the same InfoProvider.

How SAP BW/4HANA aDSO semantic keys work

An Advanced DataStore Object (aDSO) in SAP BW/4HANA is an InfoProvider that stores records in a versioned table structure: an inbound table (for newly arrived records not yet activated), an active data table (the current state used by queries), and a change log (the activation history). The semantic key is the set of InfoObject fields defined in the aDSO properties under Key Fields. The semantic key determines the aDSO’s identity logic: it is the combination of field values that uniquely identifies a record.

When an aDSO activation run processes a batch of inbound records, it compares each inbound record’s key field values against the active data table. If a matching record exists in the active table (all key field values match), the activation run marks the inbound record as RECORDMODE = U (update) and applies the delta — writing the new field values over the existing record. If no match exists, the activation run marks the inbound record as RECORDMODE = N or space (new insert) and adds it to the active table. A write-optimized aDSO stores the full record on update rather than computing a before/after delta image; the result is that an update unconditionally replaces the matched record with the incoming record’s data.

The critical implication: if two records from two different source systems share the same key field values — because the semantic key does not include a source-system discriminator — the second record to arrive will overwrite the first. The aDSO does not check the source system of the incoming record; it checks only the key fields. For a single-source aDSO, this is correct behavior. For a multi-source aDSO (loading from both a legacy ECC system and a new S/4HANA system), the semantic key must include 0LOGSYS (or a custom source-system field) to ensure that an ECC record with AUFNR 4000004001 and an S/4HANA record with AUFNR 4000004001 are treated as distinct records rather than as the same work order in different states.

-- BW4P: ZGBU_WO_HIST aDSO key field configuration
-- BW Modeling Tool → aDSO ZGBU_WO_HIST → Properties → Key Fields

-- BEFORE fix (original design):
Key Fields:
  AUFNR    (Order Number, NUMC 12)    ← only key field

Data Fields (sample):
  IWERK    (Planning Plant)
  QMNUM    (Notification Number)
  AUART    (Order Type)
  ERDAT    (Creation Date)
  ERNAM    (Created By)
  GLTRP    (Basic Finish Date)
  GSTRP    (Basic Start Date)
  OBJNR    (Object Number)
  STATUS   (System Status)
  ARBPL    (Work Center)
  KOSTL    (Cost Center)
  0LOGSYS  (Logical System)           ← data field only, NOT in key — this is the bug

-- AFTER fix:
Key Fields:
  AUFNR    (Order Number, NUMC 12)
  0LOGSYS  (Logical System, CHAR 10)  ← added to key

-- With 0LOGSYS in the key:
--   ECC record:    AUFNR=4000004001, LOGSYS='ECCP'  → unique key composite
--   S/4HANA record: AUFNR=4000004001, LOGSYS='S4P'  → different key composite
--   No collision. Both records coexist in the active table.

Diagnosis: aDSO change log and DTP Monitor

The first diagnostic step was the BEx query anomaly itself: 847 work orders with OPEN status and creation dates from 2013 through 2018. Work orders created between 2013 and 2018 should not be open in October 2026; GBUA’s maintenance operations team confirmed that all work orders from that period had been completed and closed years ago. The presence of completion dates was expected in the historical records — and was now absent, replaced by the CMMS backload data.

The SAP BW developer retainer opened the BW Workbench (transaction RSA1) and navigated to the aDSO ZGBU_WO_HIST to display the change log. The change log for the October 3 activation batch showed the anomaly immediately:

-- BW4P: aDSO ZGBU_WO_HIST change log (last 2 activation batches)
-- Transaction: RSDIPRO → ZGBU_WO_HIST → Display Change Log

Activation Batch: 20261003_230147 (PC_PM_DAILY, Oct 3)
  Records loaded: 847
  RECORDMODE distribution:
    RECORDMODE = ' ' (new):    0
    RECORDMODE = 'N' (new):    0
    RECORDMODE = 'U' (update): 847   ← all 847 are updates to existing records
    RECORDMODE = 'D' (delete): 0

Activation Batch: 20261002_230203 (PC_PM_DAILY, Oct 2)
  Records loaded: 12
  RECORDMODE distribution:
    RECORDMODE = ' ' (new):    12   ← 12 new work orders as expected
    RECORDMODE = 'U' (update): 0

The October 2 batch showed 12 new work orders — the expected pattern for a normal delta run picking up the day’s new S/4HANA work orders, all with AUFNRs above 4001284723. The October 3 batch showed 847 updates and zero new inserts. On a delta DTP run that was expected to deliver recently created work orders from S/4HANA, 847 updates to existing records was the signature of a key collision, not a legitimate correction run.

The DTP Monitor (transaction RSMO) for DTP_ZGBU_WO_DELTA’s October 3 run confirmed 847 records loaded and 0 errors. The DTP had no visibility into whether the activated records were new inserts or updates — that determination happens in the aDSO activation run, downstream of the DTP. From the DTP’s perspective, 847 records were extracted from the S/4HANA delta queue, passed through the transformation, and written to the aDSO inbound table successfully.

The final confirmation came from inspecting the S/4HANA delta queue directly. Connecting via RFC to the S/4HANA system S4P and querying the delta queue management table confirmed that the 847 records in question carried AUFNRs in the range 4000004001 through 4000004847 — the same range occupied by 847 ECC legacy records already in the ZGBU_WO_HIST active table under the AUFNR-only semantic key:

-- S4P (S/4HANA): delta queue inspection
-- Transaction RSA7 → DataSource ZMAINT_WO_S4 → Display Delta Queue

-- ABAP Open SQL on S4P ROOSGENER (delta queue management):
SELECT logicaldest, dsname, datapakid, minrqkey, maxrqkey, rqcount
  FROM roosgener
 WHERE logicaldest = 'BW4P'
   AND dsname      = 'ZMAINT_WO_S4'
 ORDER BY datapakid.

-- Result (October 3 delta queue package):
LOGICALDEST  DSNAME            DATAPAKID  MINRQKEY      MAXRQKEY      RQCOUNT
BW4P         ZMAINT_WO_S4      00001234   4000004001    4000004847    847

-- Confirmed: the 847 backloaded CMMS records assigned AUFNRs 4000004001–4000004847
-- These AUFNRs already exist in ZGBU_WO_HIST active table as ECC records (LOGSYS='ECCP')
-- With semantic key = AUFNR only, the aDSO activation sees these as 847 updates, not inserts

Root cause confirmed: the ZGBU_WO_HIST aDSO semantic key contained only AUFNR. The S/4HANA backloaded CMMS records (AUFNR 4000004001–4000004847) fell within the ECC legacy AUFNR range (4000000001–4001284723). The aDSO activation run found 847 matching keys in the active table and treated all 847 incoming records as updates, overwriting the ECC data with the CMMS data silently and successfully.

The fix: adding LOGSYS to the semantic key and running a full reload

The fix required four coordinated steps: a structural change to the aDSO key fields, a transformation update to ensure the new key field was populated for S/4HANA records, a content deletion and full reload to rebuild the active table with the corrected key structure, and validation of the BEx query results.

Step 1: Add 0LOGSYS to the ZGBU_WO_HIST semantic key. In the BW Modeling Tool (Eclipse-based, connected to BW4P DEV client), the developer opened the ZGBU_WO_HIST aDSO and navigated to Properties → Key Fields. The InfoObject 0LOGSYS (Logical System, CHAR 10) was added to the Key Fields list alongside AUFNR. The change was saved and a transport request was created in the DEV client (BWDK900123).

Step 2: Update the S/4HANA transformation to populate 0LOGSYS. The transformation TRFN_ZMAINT_WO_S4 (from DataSource ZMAINT_WO_S4 to aDSO ZGBU_WO_HIST) was opened in the BW Modeling Tool. The target field 0LOGSYS had no rule assigned. A constant routine was added:

-- BW4P: Transformation TRFN_ZMAINT_WO_S4
-- Target InfoObject: 0LOGSYS
-- Rule type: Constant

RESULT = 'S4P'.   " S/4HANA source system logical system name

-- BW4P: Transformation TRFN_ZMAINT_WO_ECC (historical ECC transformation, already correct)
-- Target InfoObject: 0LOGSYS
-- Rule type: Constant (existing rule, set during original ECC loading in 2025)

RESULT = 'ECCP'.  " ECC source system logical system name

-- Note: the ECC transformation already populated 0LOGSYS = 'ECCP' as a data field.
-- With 0LOGSYS now in the semantic key, the ECC full reload will correctly key
-- all 1,284,723 records as (AUFNR, LOGSYS='ECCP'), and the S/4HANA records
-- will key as (AUFNR, LOGSYS='S4P').
-- No AUFNR collision is possible between the two source systems regardless of AUFNR range.

Step 3: Delete aDSO content and run full reloads. Because the existing 1,284,723 ECC records in the ZGBU_WO_HIST active table had been loaded before 0LOGSYS was in the key, they carried LOGSYS = initial (empty string) in the key position. Adding 0LOGSYS to the key without reloading would leave the existing records with a blank LOGSYS key value, inconsistent with the new design. A full content deletion was required.

• ZGBU_WO_HIST content deleted via BW Workbench (right-click → Delete Contents → confirmed). Active table, inbound table, and change log cleared.
• Full reload DTP from ECC archive DataSource ZMAINT_WO_ECC executed: 1,284,723 records loaded with LOGSYS = ‘ECCP’. aDSO activation completed: all 1,284,723 records as RECORDMODE = N (new).
• Full reload DTP from S/4HANA DataSource ZMAINT_WO_S4 executed: 847 backloaded CMMS records + all post-migration S/4HANA work orders loaded with LOGSYS = ‘S4P’. aDSO activation completed: all S/4HANA records as RECORDMODE = N (new).

-- BW4P: ZGBU_WO_HIST post-reload record counts
-- Transaction RSDIPRO → ZGBU_WO_HIST → Manage → Contents

Active Table record count after full reload:
  LOGSYS = 'ECCP':  1,284,723 records   (all ECC legacy work orders)
  LOGSYS = 'S4P':         855 records   (847 backloaded CMMS + 8 new post-migration WOs)
  Total:            1,285,578 records

-- Activation batch for ECC full reload:
  Records loaded: 1,284,723
  RECORDMODE = ' ' (new): 1,284,723   ← all new inserts, as expected
  RECORDMODE = 'U' (update): 0

-- Activation batch for S/4HANA full reload:
  Records loaded: 855
  RECORDMODE = ' ' (new): 855         ← all new inserts, as expected (including the 847 CMMS records)
  RECORDMODE = 'U' (update): 0        ← zero updates — no key collision

Step 4: Validate BEx query results. The BEx query “Open Work Orders by Plant/Priority” was re-executed after the reload. The 847 phantom open work orders were gone. The ECC historical records with COMPLETED status were intact, with their original completion dates, plant assignments, and cost center values restored. The maintenance operations team confirmed that the open work order counts matched the S/4HANA operational system. Transport requests were imported to QA (BWQK900456) and PRD (BWPK900789) after sign-off.

Why semantic key design is a recurring SAP BW retainer problem

aDSO semantic key design is almost never revisited after initial deployment. The original GBUA BW design was technically correct for a single-source environment: when the only source was SAP ECC, AUFNR alone was a sufficient key because ECC guaranteed AUFNR uniqueness within a single system. The design became incorrect the moment a second source system was added — not because of a programming error, but because the assumption embedded in the key (one source system, globally unique AUFNR) was no longer valid.

This pattern repeats across SAP BW landscapes. An aDSO designed for a single source system is later fed by a second source (a new S/4HANA system after migration, an acquired company’s ERP, a third-party operational system). If the aDSO key was designed without 0LOGSYS or a custom source-system field, the new source can silently overwrite existing records any time a key value from the new source falls within the range already occupied by the original source. The collision does not fail; it does not produce an error in the DTP or the activation run. The only symptom is wrong data in query results — and only then if someone notices that the data has changed in a way that should not be possible.

A SAP BW developer retainer who performs a source-system integration review — specifically auditing all aDSO semantic keys for the presence of a source-system discriminator before a second DataSource is connected to an existing aDSO — catches this before any data is corrupted. For existing deployments with multiple DataSources already feeding the same aDSO, the audit question is: does the semantic key include 0LOGSYS or an equivalent discriminator? If not, is the AUFNR (or equivalent business key) range guaranteed non-overlapping across all source systems? If either answer is uncertain, a full reload with 0LOGSYS in the key is the only safe path. The audit takes 1–2 hours per aDSO and is a standard retainer deliverable during any S/4HANA migration or multi-source BW integration project.

How HourTab helps SAP BW developer retainers

The Great Basin Utility Authority engagement totaled 5.5 hours: diagnosis (1.5h — 0.5h reviewing the BEx query anomaly with the maintenance operations team to identify the 847 affected work orders and confirm that their creation dates and COMPLETED status from the ECC system were now replaced with incorrect OPEN status data; 0.5h reviewing the ZGBU_WO_HIST change log in RSDIPRO to find the October 3 activation batch showing 847 RECORDMODE = U records, and comparing against the October 2 batch showing 12 RECORDMODE = N records to confirm the anomaly was specific to the October 3 DTP run; 0.5h inspecting the S/4HANA delta queue via RSA7 to identify the 847 backloaded CMMS records in AUFNR range 4000004001–4000004847 and confirming the AUFNR range overlap with the ECC legacy records in the aDSO active table), fix and reload coordination (2.5h — 0.5h adding 0LOGSYS to the ZGBU_WO_HIST semantic key in the BW Modeling Tool and updating the TRFN_ZMAINT_WO_S4 transformation constant routine, transport request creation and DEV activation; 0.5h aDSO content deletion and coordination with the BW basis team to confirm the PRD content deletion window; 1.0h executing and monitoring the ECC full reload DTP run for 1,284,723 records and the S/4HANA full reload DTP run for 855 records, including aDSO activation for both batches; 0.5h transport import to QA, QA validation run, and transport import to PRD after operations sign-off), and validation (1.5h — 0.5h re-executing the BEx query “Open Work Orders by Plant/Priority” and reviewing results with the maintenance operations team; 0.5h spot-checking a sample of the 847 formerly-overwritten ECC records to confirm COMPLETED status and original plant assignments were restored; 0.5h post-incident documentation and retainer SOP update recommending 0LOGSYS audit for all aDSOs before multi-source DataSource connections are added).

In a HourTab retainer log, the incident session reads: “ZGBU_WO_HIST aDSO semantic key collision; BW/4HANA 2.0 SP10, BW4P; semantic key AUFNR only; S/4HANA migration consultant backloaded 847 CMMS work orders assigned AUFNRs 4000004001–4000004847 — within existing ECC AUFNR range; October 3 delta DTP DTP_ZGBU_WO_DELTA: 847 records loaded, 0 DTP errors, but activation treated all 847 as updates (RECORDMODE=U); result: 847 ECC COMPLETED work orders overwritten with S/4HANA CMMS data (OPEN status, wrong plant assignments); BEx query ‘Open Work Orders by Plant/Priority’ showed 847 phantom open WOs; fix: 0LOGSYS added to ZGBU_WO_HIST semantic key; TRFN_ZMAINT_WO_S4 transformation updated with constant routine LOGSYS=‘S4P’; aDSO content deleted; full reload from ECC DataSource: 1,284,723 records LOGSYS=‘ECCP’; full reload from S/4HANA DataSource: 855 records LOGSYS=‘S4P’; validation: BEx query clear, ECC historical records intact, 847 phantom WOs resolved; transport requests BWDK900123/BWQK900456/BWPK900789; 5.5h (1.5h diagnosis + 2.5h fix/reload + 1.5h validation).” The operations director at Great Basin Utility Authority sees the exact cause (missing LOGSYS in semantic key), the scope of data affected (847 records, specific AUFNR range), the fix applied (key field change plus full reload from both source systems), and the validation outcome — with no ambiguity about how the retainer time was spent.

HourTab turns a time-tracker CSV into a public retainer-hours URL your client can bookmark — no login, no portal, no “how many hours do I have left?” emails. Free for one retainer. $9/mo for up to ten.

FAQ: SAP BW developer retainers

See also: Hyperion developer retainer · MicroStrategy developer retainer · Cognos developer retainer