Summary
Two collections refresh the aggregate stock figures that Adobe Commerce/Magento 2 holds on a product record itself, as opposed to the per-source inventory rows beneath it. One covers simple products, and one covers the stock status carried on a configurable parent.
The equivalent refresh for a product variant is a separate collection, documented in the iPaaS.com to Adobe Commerce/Magento 2 Product Variant Inventory Totals Mapping Documentation article.
They exist to close a specific gap. When inventory moves and nothing else about the product changes, the movement is transferred as an inventory-only update: the quantity held against each individual Magento inventory source is refreshed, but the product's own aggregate total and stock status are not recalculated. A product can therefore keep showing a stale total, and can remain flagged as in stock, after its locations have been drawn down to zero. These collections run the follow-up pass that corrects the product record itself.
Both ship disabled behind an always-false guard in their mapping filters. Enabling them in the interface is not sufficient — the guard must be removed as well. They ship off because parent-total updates cost additional API calls on both sides.
ID Format
Manual Sync ID Format
Enter the iPaaS.com Product record identifier, for example 58231. Both collections documented here act on product records.
These collections read the product record and re-sum its inventory; they are not driven by an inventory record identifier. The variant equivalent takes a Product Variant record identifier instead.
External ID Format
These collections update a product already linked to Adobe Commerce/Magento 2 and do not mint a new external-ID record. The link established by the original product transfer is what routes the update to the correct Magento record.
Deleted Record Support
Outbound delete is not supported. These collections only refresh stock figures on records that already exist in Adobe Commerce/Magento 2, and delete mappings are not included in the default templates.
Custom Field Support
These collections read two iPaaS.com custom fields on the product record, which must exist by these exact names for the behavior they control to work:
Parent Always In Stock, read by both collections, forcing the product to remain in stock regardless of the summed inventory.
Parent Item, read by the configurable stock status collection. A value of True forces the parent to be treated as in stock regardless of the summed inventory.
A catalog that does not use always-in-stock behavior does not need these fields; the summed inventory then decides the status on its own.
Mapping Collection Status
Status: Disabled. Both collections ship with an always-false condition at the front of their mapping filters, so no record can satisfy them as delivered.
Trigger Events: A secondary update raised in iPaaS.com when inventory moves for a product whose other attributes have not changed, plus Manual Sync on demand.
The secondary-update condition is what makes these collections a follow-up pass rather than a duplicate of the main product transfer. The main product update collections deliberately exclude those same flagged records so that an inventory movement does not re-send a complete product payload, and these collections pick them up instead and write only the stock figures.
To enable a collection, remove the leading always-false condition from its mapping filter and enable the collection in the interface. Doing only one of the two leaves it inert.
Duplicate or Conflicting Mappings
These collections overlap with every other inventory path in the integration:
The standalone product inventory collections write the per-source rows that these collections then sum.
Update Adobe Commerce/Magento 2 Simple Associated Product Variant Inventory Totals FROM iPaaS.com does the equivalent work at variant level and is documented in its own article.
The simple product inventory and configurable product inventory child collections do the same beneath the product transfers.
The main simple product and configurable product update collections write the full product payload, and exclude secondary-update records precisely so these collections can handle them.
The two collections here are scoped apart from one another by their filters: the simple product totals collection requires a tracking method of Product, and the configurable stock status collection requires a tracking method of Variant. Review both filters before enabling both.
Because all of these paths can target the same Magento records, subscribers or their MiSP should review their filters and their Add and Update settings together before enabling any of them. Enabling several inventory paths against the same records without reviewing them leaves the last transfer to run deciding the figure in Magento.
Duplicate matching
This integration implements no selectable collision-handling methods, and the behavior is not configurable on these collections. Each writes to the Magento product or variant identified by its Sku, replacing the values it maps.
Unmapped field overwrite risk
These collections write stock figures only — no name, price, category, tax class, or visibility data is sent. The fields they do map are written as a full replacement each run, so a total or stock status adjusted by hand in the Magento admin is replaced on the next run.
Because the null-handling behavior on the underlying product update is not guaranteed by the integration, subscribers or their MiSP should validate in a staging environment which fields are affected on their own store before enabling these collections in production.
The fields at risk are the ones these collections map: Sku, StockItemQty and StockItemIsInStock on the simple product totals collection, StockItemIsInStock alone on the configurable stock status collection, plus UpdatedAt and AlwaysInStockOverride on both.
The mitigation is a DestinationValue. Where a Magento field must hold a specific value that the source system does not supply, set a DestinationValue on that mapping so the integration writes the value chosen there instead of taking it from the source.
Supported Child Collections
None. Both are standalone collections with no parent and no children. Each writes a single record's stock figures and has no subordinate data to contribute.
System Caveats
Adobe Commerce/Magento 2 Caveats
The product must already exist in Magento. These collections refresh figures on existing records and never create one.
A configurable product holds no saleable stock of its own. It is a container whose purchasability Magento derives from its variants, which is why the configurable collection writes a stock status but no quantity.
Aggregate refreshes cost additional API calls. This is the reason both ship disabled. Enabling them on a large catalog increases the request volume of every inventory movement, and larger stores can encounter Adobe Commerce/Magento 2 request-array and page-size limits.
iPaaS.com Caveats
The record must be flagged as a secondary update. A record that is not so flagged is out of scope for these collections and is handled by the main product update collections instead.
Quantities are summed across all of the record's iPaaS.com locations and rounded down to a whole number, because Magento tracks stock in whole units.
The always-in-stock custom fields must exist by their exact names for the override behavior to apply. A missing field simply leaves the override unset.
Integration-Specific Caveats
Enabling in the interface alone does nothing. The always-false guard lives in the mapping filter, not in the enabled flag, so a collection switched on in the interface with the guard still in place processes no records and reports no error.
The two collections are mutually exclusive by tracking method. A record with a tracking method of Product is handled by the simple product totals collection; one with Variant by the configurable stock status collection. A record whose tracking method is neither is processed by neither.
The configurable stock status collection also requires fewer than two units of measure on the record. Families carrying multiple units of measure fall outside its scope.
The simple product totals collection carries a SKU exclusion; the configurable one does not. Subscribers who need particular families held back from the configurable collection — sample records, or products whose Magento stock status is managed by hand — must add that exclusion themselves.
Setup Requirements
Adobe Commerce/Magento 2 Configuration
Confirm the products and variants these collections will refresh already exist in the store.
Confirm the store can absorb the additional request volume before enabling them on a large catalog.
iPaaS.com Configuration
Create the Parent Always In Stock and Parent Item custom fields where always-in-stock behavior is required, and populate them.
Remove the leading always-false condition from the mapping filter of each collection to be enabled.
Replace or remove the excluded example SKU in the simple product totals filter.
Review the tracking-method conditions on both collections so that each product family is handled by exactly one of them.
Enable the outbound flow for Adobe Commerce/Magento 2 inventory on the subscription's Outbound Data Flows page.
Full step-by-step setup instructions are in the Adobe Commerce/Magento 2 Installation Instructions article.
Integration Flow
Inventory moves in iPaaS.com for a product whose other attributes have not changed, and the record is flagged as a secondary update.
The main product update collection excludes the record, so no full product payload is sent.
The per-source inventory rows are refreshed by the inventory collections.
The record is evaluated against these collections' mapping filters. As shipped, the always-false guard stops it here.
With the guard removed, the matching collection re-sums the record's available inventory across all of its iPaaS.com locations, rounds the result down, and writes the total and stock status — or, for a configurable parent, the stock status alone — to the Magento record. A variant record is handled by the separate variant totals collection instead.
Mappings
Update Adobe Commerce/Magento 2 Simple Product Inventory Totals FROM iPaaS.com
iPaaS.com data type: Product
Mapping Filter
1==0 && TrackingMethod =="Product" && !(Sku == "GC-TEST-100") && SecondaryUpdate == true
This collection processes iPaaS.com product records that meet all four conditions. 1==0 is an always-false condition that no record can satisfy — the guard that ships the collection disabled, and the condition subscribers remove to enable it. TrackingMethod =="Product" restricts the collection to standalone simple products, leaving variant totals to the variant collection. The SKU condition excludes one specific record. SecondaryUpdate == true restricts it to inventory-only movements, which is what makes it a follow-up pass rather than a duplicate of the main product transfer.
Placeholder value — replace during implementation: the excluded SKU GC-TEST-100 is a test gift-card record carried over from the template environment. Replace it with the SKUs the store actually needs to exclude, or remove the exclusion if it has no meaning in the catalog.
Mapping Type | Source Field (iPaaS.com) | Destination Field (Adobe Commerce/Magento 2) | Description |
Field | Sku | Sku | Required. Identifies the Magento product whose totals are refreshed. |
Dynamic Formula |
| StockItemQty | Recommended. Sums the product's available inventory across all of its iPaaS.com locations and rounds down to a whole number, giving the product's total on-hand quantity in Magento. |
Dynamic Formula |
| StockItemIsInStock | Required. Sets whether the storefront treats the product as in stock, derived from the same summed and floored figure used for the quantity. |
Dynamic Formula |
| UpdatedAt | Optional. Stamps the product's updated date with the time the transfer ran, so the Magento record shows when the integration last refreshed its totals. |
Field | Parent Always In Stock | AlwaysInStockOverride | Optional. Carries the iPaaS.com product custom field that forces the product to remain in stock regardless of the summed quantity. |
Update Adobe Commerce/Magento 2 Configurable Product Inventory Stock Status FROM iPaaS.com
iPaaS.com data type: Product
Mapping Filter
1==0 && TrackingMethod=="Variant" && SecondaryUpdate == true && Units.Count < 2
This collection processes iPaaS.com product records that meet all four conditions. 1==0 is the always-false guard that ships it disabled. TrackingMethod=="Variant" restricts it to products modelled in Magento as a configurable family and excludes standalone products, whose totals are handled by the simple product totals collection. SecondaryUpdate == true restricts it to inventory-only movements. Units.Count < 2 excludes families carrying more than one unit of measure.
This collection carries no SKU exclusion, unlike the equivalent product-level collection. Every record satisfying the four conditions is in scope once the guard is removed.
Mapping Type | Source Field (iPaaS.com) | Destination Field (Adobe Commerce/Magento 2) | Description |
Field | Sku | Sku | Required. Identifies the Magento configurable parent whose stock status is refreshed. |
Dynamic Formula |
| StockItemIsInStock | Recommended. Sets the stock status carried on the configurable parent. A Parent Item custom field of True forces the parent in stock; otherwise the status follows the summed inventory. No quantity is written, because a configurable product holds no saleable stock of its own. |
Dynamic Formula |
| UpdatedAt | Optional. Stamps the parent's updated date with the time the transfer ran. |
Field | Parent Always In Stock | AlwaysInStockOverride | Optional. Carries the iPaaS.com product custom field that forces the parent to remain in stock regardless of the summed inventory. |
Error Handling
The full catalog of messages this integration produces, with causes and resolutions, is in the Adobe Commerce/Magento 2 Error Messages article. The conditions most often seen on these transfers are:
No records processed at all. The always-false guard is still present in the mapping filter. This produces no error, because no record ever reaches the transfer. Resolution: remove the guard from the filter as well as enabling the collection.
A product or variant rejected for an unknown SKU. The record does not exist in Magento under the mapped SKU. Resolution: transfer the product or variant first, then re-run.
A stale total after inventory has moved. The record was not flagged as a secondary update, so it fell outside these collections' scope. Resolution: confirm the inventory movement raised a secondary update, and check the main product update collection's filter.
Errors are reported under Dashboard / Integration Monitoring / Error Logs.
Testing & Validation
Test Scenarios
With the guard still in place, run an inventory movement and confirm no records are processed by these collections.
Remove the guard from one collection, repeat the movement, and confirm the aggregate total and stock status are refreshed on the Magento record.
Draw a simple product's locations down to zero and confirm the product's total reads zero and its stock status flips to out of stock.
Draw every variant of a configurable family to zero and confirm the parent's stock status flips to out of stock; restock one variant and confirm it flips back.
Set Parent Item to True on a configurable product, draw its variants to zero, and confirm the parent remains flagged in stock.
Populate Parent Always In Stock and confirm the override reaches Magento.
Transfer a fractional summed quantity and confirm it is rounded down in Magento.
Confirm a product whose tracking method is Product is handled only by the simple product totals collection, and one whose tracking method is Variant only by the configurable stock status collection.
Confirm a product variant record is handled by the separate variant totals collection rather than by either collection here.
Adjust a total by hand in the Magento admin, re-run the transfer, and confirm the iPaaS.com figure replaces it.
Validation Checklist
The always-false guard has been removed from the filter of every collection intended to be enabled.
The excluded example SKU in the simple product totals filter has been replaced or removed.
The Parent Always In Stock and Parent Item custom fields exist and are populated where the behavior is required.
Each product family is handled by exactly one of the two collections.
The store can absorb the additional request volume these collections add to every inventory movement.
Additional Notes
These collections are the reason an inventory-only movement does not leave a stale total on the product record. Leaving them disabled is a deliberate trade-off: fewer API calls, at the cost of aggregate totals and stock status that can drift from the per-source rows beneath them.
Because the guard lives in the mapping filter rather than the enabled flag, a collection can appear enabled in the interface while processing nothing. Check the filter first when these transfers seem to do nothing.
Validate dynamic formulas and filter changes in a staging environment before enabling these collections in production.