/LIME/PI_LOGHEAD
transactionGUID keyPhysical inventory document header — the log header that resolves a counting document's GUID to its readable year and number, its process type, and the warehouse it was raised for
The anchor of the physical inventory area: every other counting table keys on GUID_DOC and carries no readable document number, so this is where a count is given a name a warehouse manager would recognize. The planning-object columns (IPO_YEAR / IPO_NUMBER) point at the planning document a scheduled count was generated from, which is how cyclical counting programs are told apart from ad-hoc ones.
What the badges mean
- master
- Data class: what the table holds — master data, transaction documents, configuration, an organizational object, or a language-striped text companion.
- Semantic key
- Every non-client key column is readable business data —
LGNUMplus a bin, task, or order number. Joins run on the columns you can see (see the quirks guide). - GUID key
- Every non-client key column is a GUID —
RAW(16)on the /SCWM, /SCDL, /LIME, and /SCMB tables, and theCHAR(22)compressed form on the product master. Join the raw column; a hex rendering is for reading only, and the two encodings need converting between (see the quirks guide). - Mixed key
- The key mixes readable and GUID columns in either direction — a product GUID inside an otherwise-readable bin key, or a readable status type inside an otherwise-GUID key. Check which side of a join you are on (see the quirks guide).
- DOCCAT: PDO
- A /SCDL delivery table holds several document categories in one table — inbound and outbound requests, the inbound delivery, the outbound delivery order, and the final outbound delivery — discriminated by
DOCCAT. The chips list the categories this table carries; anchor the one you mean or documents of every kind come back together (see the quirks guide). - Embedded S/4HANA only
- Deployment: shown only when a table does not exist in both embedded S/4HANA EWM and decentralized EWM. No table in this wave is deployment-specific, so the badge stays absent until one is.
Structural facts — how the table is keyed, not a trap by itself
Join & extract hazards — verify before you rely on this
Header & item
/LIME/PI_LOGHEAD is the header for its items in /LIME/PI_DOC_IT.
Fields
8 fields · 2 key
8 fields.
| # | Field | Description | Type | Flags |
|---|---|---|---|---|
| 1 | MANDT | Client | CLNT(3) | Key |
| 2 | GUID_DOC | GUID of the physical inventory document — the key every counting table hangs on | RAW(16) | Key |
| 3 | DOC_YEAR | Document year of the counting document — with the number, the readable identity of the count | NUMC(4) | |
| 4 | DOC_NUMBER | Physical inventory document number | NUMC(20) | |
| 5 | IPO_YEAR | Document year of the planning object the count was generated from | NUMC(4) | |
| 6 | IPO_NUMBER | Number of the physical inventory planning document — empty on ad-hoc counts | NUMC(20) | |
| 7 | PROCESS_TYPE | Counting process type | CHAR(4) | |
| 8 | LGNUM | Warehouse number the count was raised for | CHAR(4) |
Field provenance: hand-curated. 2 key fields.
Boilerplate SQL
Starting point for reading the replicated copy of /LIME/PI_LOGHEADon Databricks — the client anchor is already in place, the namespaced name is rendered as the underscore bronze name replication targets conventionally land it under, and any RAW16 GUID column selects a hex rendering alongside the raw value. Set your Unity Catalog location, schema, and filter values below; they’re substituted into the SQL and the copy button.
3 parameters not filled: <catalog>, <schema>, <client>
-- ============================================================
-- Table : /LIME/PI_LOGHEAD — Physical inventory document header — the log header that resolves a counting document's GUID to its readable year and number, its process type, and the warehouse it was raised for
-- Purpose: Column-selected read of /LIME/PI_LOGHEAD — auto-generated from field metadata
-- Grain : One row per client + GUID_DOC
-- Notes : Auto-generated skeleton for SAP EWM data replicated into your lakehouse — it reads the replicated copy, not the SAP database. Source table /LIME/PI_LOGHEAD; slashes aren't legal in unquoted Databricks identifiers, so replication targets conventionally land it as lime_pi_loghead — adjust to your landing convention (see quirks #namespace-slashes). RAW16 GUID columns are joined raw; the hex aliases are for display only (#guid-keys). Timestamps flagged UTC are DEC(15) yyyymmddhhmmss values in UTC, not warehouse local time (#utc-timestamps).
-- ============================================================
SELECT
t.MANDT AS "Client",
t.GUID_DOC AS "GUID of the physical inventory document — the key every counting table hangs on",
lower(hex(t.GUID_DOC)) AS "GUID of the physical inventory document — the key every counting table hangs on (hex)", -- display rendering of the RAW16 GUID — join on the raw column; see quirks guide #guid-keys
t.DOC_YEAR AS "Document year of the counting document — with the number, the readable identity of the count",
t.DOC_NUMBER AS "Physical inventory document number",
t.IPO_YEAR AS "Document year of the planning object the count was generated from",
t.IPO_NUMBER AS "Number of the physical inventory planning document — empty on ad-hoc counts",
t.PROCESS_TYPE AS "Counting process type",
t.LGNUM AS "Warehouse number the count was raised for"
FROM <catalog>.<schema>.lime_pi_loghead t
WHERE
t.MANDT = '<client>' -- client filter — drop on single-client systems
ORDER BY t.GUID_DOC;Verified August 2026
Landing conventions differ — see namespaced names in a lakehouse.
Relationships
Diagram of 1-hop neighbors — join details below. GUID joins and text-table joins are highlighted; they’re the joins newcomers most often get wrong.
Join details
ON lime_pi_loghead.MANDT = lime_pi_doc_it.MANDT AND lime_pi_loghead.GUID_DOC = lime_pi_doc_it.GUID_DOC -- the counting document's readable year and number live only on the header — every item row carries the GUID alone, so the join runs on the raw GUID column with hex reserved for displaythe counting document's readable year and number live only on the header — every item row carries the GUID alone, so the join runs on the raw GUID column with hex reserved for display
Transaction codes that touch this table
Curated: the EWM transactions an analyst would trace back to these rows, and how each one touches them.
R read · W write · R/W read + write
- /SCWM/DIFF_ANALYZERThe difference analyzer — review, approve, and clear the differences a count produced against book stockRead accessReportphysical-inventory
- /SCWM/PI_CREATECreate physical inventory documents — raise the counting work for a set of bins, handling units, or productsWrite accessCreatephysical-inventory
- /SCWM/PI_PROCESSProcess a physical inventory document — enter counts, recount, and post the resultRead accessChangephysical-inventory
More Physical Inventory tables
- /LIME/PI_PAR_BIZPhysical inventory parent business keys — the readable location behind a document item's parent object: warehouse, storage type, bin, handling unit, resource, or transportation unit
- /LIME/PI_DOC_ITPhysical inventory document item — the countable line: its type and status, when it was created, counted, and posted, who counted it, the physical inventory area it belongs to, and the completeness flags that say whether a bin or handling unit was counted whole
- /LIME/PI_DOC_TBPhysical inventory quantities — the book and counted quantities behind a document item, one row per quantity parameter per unit of measure
- /LIME/PI_IT_BIZPhysical inventory item business keys — the readable stock identity behind a document item: product, batch, stock type, owner and entitled party, plus the location and handling unit the stock was counted in