Inventory anomaly reporting and remediation procedures

While the Inventory Integrity Dashboard provides a macro-level view of network health, the Report Generation tool equips fulfillment managers with the precise, actionable datasets required to execute targeted cleanups. By extracting exactly which items are causing discrepancies, operational teams can validate anomalies against merchandising plans and programmatically purge invalid records from the system.

Report Generation Engine

The reporting engine allows users to extract comprehensive CSV datasets that mirror the schema of the GET Supply API. Because these reports contain the exact supply identifiers needed for remediation, they seamlessly bridge the gap between identification and correction.

To ensure peak system performance and enforce data freshness, the reporting architecture operates under strict technical parameters:
  • Targeted Filtering
    Users can filter reports by specific SKUs and Nodes and may use comma-separated bulk entry. To avoid operational bottlenecks, it is recommended to execute complete syncs and reports in strategic batches of nodes or specific SKU categories.
  • Lookback Parameters
    Depending on the report type, users can select a trailing lookback period of 7, 14, 30, 60, or 90 days, or isolate a specific historical month.
  • Quota and Governance
    To balance system performance vs reporting, tenant environments are strictly metered to an upper limit of 25 report generations per day. The quota counter resets daily.
  • Freshness and Retention
    Generated reports are tracked via a Job Status monitor. Once completed, the CSV artifact is available for download with a strict 7-day retention policy (Time-to-Live). After 7 days, the file expires and is purged from the system, forcing users to generate a fresh report to prevent remediation actions based on stale data drift.

Core anomaly reports

Fulfillment managers can request the following targeted reports to isolate specific inventory health failures:
  • Stagnant SKU Report
    Generates a list of supply records exhibiting zero activity within the selected lookback period. This acts as the master list for identifying both Phantom and Dormant items.
  • Phantom SKU Report
    Isolates supply records with no activity that were missed during recent supply sync requests or cycle counts. These represent ghost inventory no longer physically maintained in the warehouse and are immediate candidates for system purging.
  • Dormant SKU Report
    Identifies items that show no sales or adjustment activity but were included in recent cycle counts. These represent valid, physically present inventory that is slow-moving, signaling a need for promotional events or merchandising markdowns.
  • Zombie SKU Report
    Exposes records previously purged or marked as unavailable that have resurrected with a positive quantity within the lookback period. This indicates a critical failure in an upstream system (such as an ERP or WMS) transmitting a faulty resync. Remediation requires investigating the source integration to stop the loop.
  • Deadstock SKU Report
    Lists excess inventory with absolutely no movement for over 365 days. These items are prime targets for financial write-offs or asset repurposing.

Post-sync verification - validation loop

The Post-Sync Verification Report is a specialized, time-sensitive workflow executed immediately after a bulk cycle count or full inventory synchronization. Its purpose is to definitively identify any SKUs that were completely missed during the sync payload.
  • Baseline Parameter
    When generating this report, the manager must input the exact date of the bulk sync. For example, if a node finalized a complete cycle count on May 10, 2026, that date is set as the baseline.
  • Execution Window
    The system allows a maximum baseline lookback of 14 days from the date of the request. However, to eliminate data drift, it is highly recommended to execute this report within 1 to 2 days of the physical count.
  • Stagnancy Filter
    By default, the report enables the "limit to stagnant inventory only" flag to isolate problematic inactive SKUs. User can uncheck this to retrieve a raw list of all un-synced items, regardless of activity status.
Any excess records returned by this verification process must be reviewed against current merchandising plans and urgently purged if deemed invalid.

Programmatic Remediation: The Purge Workflow

Once invalid supply records such as Phantom SKUs are identified via the CSV reports, they must be permanently stripped from the fulfillment network. Applying a standard zero-quantity update is insufficient, as the record itself remains in the database, risking future invalid sales capture damaging customer experience and increases fulfillment handling cost.

Remediation is executed via the PUT Supply Sync API - PUT https://api.watsoncommerce.ibm.com/inventory/){tenantId}/v1/supplies. To completely eradicate the anomaly, the payload must combine a zero quantity with the strict purgeSupply directive.
Required payload flags
  • "quantity": 0
  • "purgeSupply": true
Example - Remediation supply payload
{
  "supplies": [
  {
     "itemId": "SKU1024",
     "unitOfMeasure": "EACH",
     "productClass": "NEW",
     "type": "ONHAND",
     "shipNode": "Matrix-Store-001",
     "segment": "ONLINE",
     "segmentType": "Channel",
     "inventoryTag": {
        "batchNo": "B1",
        "lotNumber": "L1",
        "revisionNo": "R1"
     },
     "quantity": 0,
     "purgeSupply": true
     }
  ]
}

By executing this exact payload, the supply record is removed from the inventory system. This critical step guarantees that the phantom SKU is never presented on a Product Detail Page (PDP) and aligns all downstream event publishing with the actual physical reality of the warehouse.