Skip to main content

iPaaS.com to Adobe Commerce/Magento 2 Product Variant Inventory Totals Mapping Documentation

How the aggregate stock totals and stock status held on an Adobe Commerce/Magento 2 product variant are refreshed after an inventory-only movement.

Summary

The aggregate stock figures Adobe Commerce/Magento 2 holds on a product variant record are refreshed from iPaaS.com. The variant's available inventory is re-summed across all of its iPaaS.com locations, rounded down to a whole number, and written to the Magento variant as its total on-hand quantity together with the matching stock status flag.

This collection exists to close a specific gap. When inventory moves and nothing else about the variant changes, the movement is transferred as an inventory-only update: the quantity held against each individual Magento inventory source is refreshed, but the variant's own aggregate total and stock status are not recalculated. A variant can therefore keep showing a stale total, and can remain flagged as in stock, after its locations have been drawn down to zero. This is the follow-up pass that corrects the variant record itself.

It runs only for records flagged as a secondary update — the signal iPaaS.com raises when inventory moves for a record whose other attributes have not changed.

This collection ships disabled behind an always-false guard in its mapping filter. Enabling it in the interface is not sufficient — the guard must be removed as well.

ID Format

Manual Sync ID Format

Enter the iPaaS.com Product Variant record identifier — the internal numeric identifier of the variant in iPaaS.com, for example 58244.

This collection reads the variant record and re-sums its inventory; it is not driven by an inventory record identifier, and the variant SKU is not accepted as a Manual Sync value.

External ID Format

This collection updates a variant already linked to Adobe Commerce/Magento 2 and does not mint a new external-ID record. The link established by the original product variant transfer is what routes the update to the correct Magento variant.

Deleted Record Support

Outbound delete is not supported. This collection only refreshes stock figures on variants that already exist in Adobe Commerce/Magento 2, and delete mappings are not included in the default templates.

Custom Field Support

This collection reads one iPaaS.com custom field on the product variant record:

  • Child Always In Stock: forces the variant to remain in stock regardless of the summed quantity.

A catalog that does not use always-in-stock behavior does not need the field; the summed inventory then decides the status on its own.

Mapping Collection Status

Status: Disabled. This collection ships with an always-false condition at the front of its mapping filter, so no record can satisfy it as delivered.

Trigger Events: A secondary update raised in iPaaS.com when inventory moves for a variant whose other attributes have not changed, plus Manual Sync on demand.

The secondary-update condition is what makes this a follow-up pass rather than a duplicate of the main product transfer. The configurable product update collections deliberately exclude those same flagged records so that an inventory movement does not re-send a complete family payload, and this collection picks them up instead and writes only the variant's stock figures.

To enable it, remove the leading always-false condition from the mapping filter and enable the collection in the interface. Doing only one of the two leaves it inert.

Duplicate or Conflicting Mappings

This collection overlaps with every other inventory path that touches a variant:

  • Add / Update Adobe Commerce/Magento 2 Simple Associated Product Variant Inventory FROM iPaaS.com writes the per-source rows beneath the configurable product transfers that this collection then sums.

  • Add / Update Adobe Commerce/Magento 2 Standalone Product Variant Inventory FROM iPaaS.com writes the same per-source rows without a product transfer above them.

  • Add / Update Adobe Commerce/Magento 2 Simple Associated Product Variant FROM iPaaS.com writes the full variant payload, and its update half excludes secondary-update records precisely so this collection can handle them.

  • Update Adobe Commerce/Magento 2 Simple Product Inventory Totals FROM iPaaS.com and Update Adobe Commerce/Magento 2 Configurable Product Inventory Stock Status FROM iPaaS.com do the equivalent work at product level rather than variant level. They are documented together in the Product Inventory Totals article.

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.

Duplicate matching

This integration implements no selectable collision-handling methods, and the behavior is not configurable on this collection. It writes to the Magento variant identified by its Sku, replacing the values it maps.

Unmapped field overwrite risk

This collection writes stock figures only — no name, price, category, tax class, or visibility data is sent. The fields at risk are Sku, StockItemQty, StockItemIsInStock, UpdatedAt and AlwaysInStockOverride. Each is written as a full replacement every 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 variant 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 this collection in production.

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. This is a standalone collection with no parent and no children. It writes a single variant's stock figures and has no subordinate data to contribute.

System Caveats

Adobe Commerce/Magento 2 Caveats

  • The variant must already exist in Magento. This collection refreshes figures on existing records and never creates one.

  • The variant is what holds sellable stock. A configurable parent is a container whose purchasability Magento derives from its variants, so these are the figures that drive storefront availability for the family.

  • Aggregate refreshes cost additional API calls. This is the reason the collection ships disabled. Enabling it 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 variant record that is not so flagged is out of scope and is handled by the configurable product update collections instead.

  • Quantities are summed across all of the variant's iPaaS.com locations and rounded down to a whole number, because Magento tracks stock in whole units.

  • The always-in-stock custom field must exist by its exact name for the override 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.

  • This collection carries no tracking-method condition and no SKU exclusion, unlike the two product-level totals collections. Every variant record flagged as a secondary update is in scope once the guard is removed. Subscribers who need particular variants held back must add that exclusion themselves.

  • It does not refresh the configurable parent. The parent's stock status is the subject of the configurable stock status collection, documented in the Product Inventory Totals article.

Setup Requirements

Adobe Commerce/Magento 2 Configuration

  • Confirm the variants this collection will refresh already exist in the store.

  • Confirm the store can absorb the additional request volume before enabling it on a large catalog.

iPaaS.com Configuration

  • Create the Child Always In Stock custom field on product variant records where always-in-stock behavior is required, and populate it.

  • Remove the leading always-false condition from the mapping filter.

  • Add an exclusion to the filter where particular variants should be held back, since the collection ships with none.

  • Review this collection alongside the variant inventory collections and the product-level totals collections, so only the intended paths are active.

  • 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

  1. Inventory moves in iPaaS.com for a variant whose other attributes have not changed, and the record is flagged as a secondary update.

  2. The configurable product update collection excludes the record, so no full family payload is sent.

  3. The per-source inventory rows are refreshed by the variant inventory collections.

  4. The record is evaluated against this collection's mapping filter. As shipped, the always-false guard stops it here.

  5. With the guard removed, the collection re-sums the variant's available inventory across all of its iPaaS.com locations, rounds the result down, and writes the total and stock status to the Magento variant, together with the updated-date stamp and the always-in-stock override.

Mappings

Update Adobe Commerce/Magento 2 Simple Associated Product Variant Inventory Totals FROM iPaaS.com

iPaaS.com data type: Product Variant

Mapping Filter

1==0 && SecondaryUpdate == true

This collection processes iPaaS.com product variant records flagged as a secondary update. 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. 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.

Unlike the two product-level totals collections, this one carries no tracking-method condition and no SKU exclusion. Every variant record flagged as a secondary update 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 variant whose totals are refreshed.

Dynamic Formula

var result = await SumInventoryForVariantAsync(ConvertToLong(Id)); return Floor(result);

StockItemQty

Recommended. Sums the variant's available inventory across all of its iPaaS.com locations and rounds down to a whole number, giving the variant's total on-hand quantity in Magento.

Dynamic Formula

var result = await SumInventoryForVariantAsync(ConvertToLong(Id)); var result2 = Floor(result); (result2 <= 0 ? return false; : return true;)

StockItemIsInStock

Required. Sets whether the storefront treats the variant as in stock, derived from the same summed and floored figure used for the quantity.

Dynamic Formula

CurrentDateTime()

UpdatedAt

Optional. Stamps the variant's updated date with the time the transfer ran, so the Magento record shows when the integration last refreshed its totals.

Field

Child Always In Stock

AlwaysInStockOverride

Optional. Carries the iPaaS.com variant custom field that forces the variant to remain in stock regardless of the summed quantity.

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 this transfer 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 variant rejected for an unknown SKU. The variant does not exist in Magento under the mapped SKU. Resolution: transfer the 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 this collection's scope. Resolution: confirm the inventory movement raised a secondary update, and check the configurable product update collection's filter.

Errors are reported under Dashboard / Integration Monitoring / Error Logs.

Testing & Validation

Test Scenarios

  1. With the guard still in place, run an inventory movement against a variant and confirm no records are processed by this collection.

  2. Remove the guard, repeat the movement, and confirm the aggregate total and stock status are refreshed on the Magento variant.

  3. Draw a variant's locations down to zero and confirm its total reads zero and its stock status flips to out of stock.

  4. Restock the variant from zero and confirm both are refreshed.

  5. Populate Child Always In Stock and confirm the override reaches Magento and holds the variant in stock at zero quantity.

  6. Transfer a fractional summed quantity and confirm it is rounded down in Magento.

  7. Confirm the configurable parent's own stock status is not refreshed by this collection.

  8. Adjust a variant total by hand in the Magento admin, re-run the transfer, and confirm the iPaaS.com figure replaces it.

  9. Confirm a variant record not flagged as a secondary update is handled by the configurable product update collection instead.

Validation Checklist

  • The always-false guard has been removed from the filter if the collection is intended to be enabled.

  • The Child Always In Stock custom field exists and is populated where the behavior is required.

  • An exclusion has been added to the filter where particular variants should be held back.

  • Only the intended inventory paths are enabled against the same variants.

  • The store can absorb the additional request volume this collection adds to every inventory movement.

Additional Notes

  • This collection is the reason an inventory-only movement does not leave a stale total on a variant record. Leaving it disabled is a deliberate trade-off: fewer API calls, at the cost of aggregate totals that can drift from the per-source rows beneath them.

  • Because the guard lives in the mapping filter rather than the enabled flag, the collection can appear enabled in the interface while processing nothing. Check the filter first when this transfer seems to do nothing.

  • The product-level equivalents — simple product totals and configurable parent stock status — are documented in the Product Inventory Totals article.

  • Validate dynamic formulas and filter changes in a staging environment before enabling this collection in production.

Related Documents

Did this answer your question?