Restore Capacity-Aware Product Network Availability Calculation in Inventory Visibility (IV)

Product Area

Sterling Intelligent Promising (SIP) – Inventory Visibility (IV)

Background

Prior to the June 2026 release and the introduction of the new capacity model in Inventory Visibility (IV), Product Network availability calculations supported capacity-aware inventory aggregation through the considerCapacity attribute available on the following APIs:

• /inventory/{tenantId}/v2/availability/network
• /inventory/{tenantId}/v2/availability/{itemId}/network/{distributionGroupId}

When the considerCapacity parameter was enabled, Inventory Visibility considered both inventory availability and the underlying node fulfillment capacity when calculating Product Network availability. This ensured that inventory from capacity-constrained nodes did not contribute to the available-to-promise (ATP) quantity returned by these APIs. This functional requirement was already discussed and raised as part of an existing RFE https://ideas.ibm.com/ideas/SIP-I-34

Following the June 2026 release and the introduction of the new capacity model, the considerCapacity capability was deprecated and is no longer supported for Product Network availability calculations. We have been informed that this behavior will not be reinstated within the current implementation and that a Request for Enhancement (RFE) should be raised if customers require this functionality going forward.

As this capability was previously relied upon to ensure accurate ATP calculations and realistic Product Network availability, we are submitting this RFE to request that capacity-aware Product Network availability be restored as a supported capability.

Enhancement Request

Introduce the ability for Inventory Visibility to consider the operational capacity of underlying ship nodes when calculating Product Network availability. This is the availability shown to customer on product listing page, product details page, basket to place the order.

When a Product Network consists of multiple ship nodes, inventory held at a node that has exhausted its fulfillment capacity should not contribute to the aggregate Product Network availability returned by availability APIs.

In other words, Product Network availability should be constrained by both:

• Inventory availability
• Node fulfillment capacity

Current Behaviour

Currently, Product Network availability is calculated based on inventory positions across all eligible nodes within the network.

A node continues to contribute inventory to the Product Network availability calculation even when:

• The node has reached its configured pick, pack, or fulfillment capacity.
• The node is operationally unable to process additional orders.
• The node would not be eligible for sourcing due to capacity constraints.

This can result in Product Network availability being overstated and inventory being reported as available despite being operationally unavailable for fulfillment.

Desired Behaviour

When evaluating Product Network availability:

1. Inventory Visibility should evaluate inventory availability together with node fulfillment capacity.
2. Nodes that have exhausted their available capacity should be treated as temporarily unavailable for promising purposes.
3. Inventory from capacity-constrained nodes should be excluded from the Product Network availability calculation.
4. Once capacity becomes available again, the node should automatically contribute inventory back into the Product Network calculation.
5. The capability should be available through a supported API parameter, configuration setting, or equivalent mechanism similar to the previously available considerCapacity functionality.

Example

Product Network Composition

Current Result

Network Availability = 95 units

Node D inventory contributes to the Product Network availability even though the node cannot fulfill additional demand because its capacity has been exhausted.

Requested Result

Network Availability = 45 units

Node D inventory should be excluded from the Product Network availability calculation until fulfillment capacity becomes available again.

Business Impact

The removal of capacity-aware Product Network availability has created a gap between reported inventory availability and actual fulfillment capability.

This can lead to:

• Over-promising inventory to downstream channels.
• Inaccurate ATP calculations.
• Increased order re-sourcing and fulfillment exceptions.
• Additional operational overhead.
• Degraded customer experience due to promise revisions.
• Reduced trust in Product Network availability figures.
• Existing integrations and business processes that relied on the historical considerCapacity functionality can no longer obtain capacity-aware network availability using the standard IV APIs.
• Customers are forced to implement custom logic outside SIP to replicate functionality that was previously available out of the box.
• Increased integration complexity, maintenance effort, and risk of inconsistent ATP calculations across channels.

Business Value

Reintroducing capacity-aware Product Network availability would:

• Improve ATP accuracy.
• Align inventory visibility with real-world fulfillment capability.
• Ensure only fulfillable inventory contributes to Product Network availability.
• Reduce fulfillment exceptions and manual intervention.
• Improve customer promise reliability.
• Better support peak trading periods and constrained-capacity scenarios.
• Reduce the need for custom integrations and workarounds outside SIP.
• Restore functionality that previously existed and was successfully used by customers prior to the June 2026 capacity model changes.

Use Cases

• Peak season fulfillment capacity constraints.
• Warehouse staffing shortages.
• Temporary operational disruptions.
• Dynamic capacity throttling.
• High-volume fulfillment networks where inventory availability alone is insufficient to determine true fulfillment capability.
• Enterprise ATP implementations that depend on Product Network availability for sourcing and promise calculations.

Requested Outcome

We request that IBM restore, or provide an equivalent supported mechanism to, the previously available considerCapacity functionality for Product Network Availability APIs.

The solution should ensure that inventory from capacity-constrained nodes does not contribute to Product Network availability until the node regains available fulfillment capacity.

This would restore the ability to calculate Product Network availability based on both inventory position and operational fulfillment capacity, resulting in more accurate ATP calculations and more reliable customer promises.

Business Priority: High

The deprecation of the historical considerCapacity capability has created a functional gap for customers that rely on Product Networks as an aggregate ATP construct and require availability calculations to accurately reflect both stock availability and fulfillment capacity.