NCR Counterpoint to iPaaS.com Product Variant Inventory Mapping Documentation

This mapping collection brings a product variant's stock figures from NCR Counterpoint into iPaaS.com for the first time, creating the inventory record that ties a variant to the location its stock sits at. It carries the quantity available for that variant, the quantity on hand, a cost figure, the location itself, and the link to the product variant the inventory belongs to.

This family does not itself carry deletions. Where a separate Delete collection exists for this entity it handles removals from Counterpoint to iPaaS.com; otherwise a removal in Counterpoint is not propagated. See NCR Counterpoint Known Limitations.

Important: these collections operate on the same NCR Counterpoint variant inventory records. This collection and Update NCR Counterpoint Product Variant Inventory TO iPaaS.com share the same trigger set, and routing between them is decided by the external-ID link rather than by which trigger fired, so enabling both is the normal configuration. Add/Update NCR Counterpoint Product Variant Inventory TO iPaaS.com reaches the same records by a different route, as part of a variant transfer. Subscribers or their MiSP should review all three collections' filters and Add/Update settings before enabling any of them, and should treat NCR Counterpoint as the source of truth for stock figures where the same variants are also maintained in another connected system.

Mapping Filter

Filter Description.

The filter first assembles the variant's SKU, then looks that SKU up against the product variants already transferred into iPaaS.com. Where no matching variant is found the filter returns false and the inventory record is skipped; where a match is found it returns true and the record transfers.

The SKU is assembled from the item number and the item's grid dimensions, joined with pipe characters. The first dimension is always included. The second and third are included only where they hold a value other than an asterisk — NCR Counterpoint uses an asterisk to mean that dimension is not in use for that item. So a two-dimension item such as a shirt sized by colour and size produces a SKU of item number, colour, and size, while a one-dimension item produces a SKU of item number and that single dimension only.

This same construction is repeated in the ParentId mapping in this collection, and the two must agree. Subscribers or their MiSP who change how the SKU is built in one place must make the identical change in the other, or the filter will admit records that ParentId cannot then resolve.

Source: QTY_AVAIL · Destination: QtyAvailable

This is a recommended field. The endpoint description for variant inventory does not list it as required, so iPaaS.com accepts an inventory record without it, but available quantity is the figure most downstream systems read to decide what can be sold, so it should be mapped for any meaningful inventory sync.

The quantity available for this variant at this location as NCR Counterpoint calculates it — on-hand stock less amounts already committed to orders. It is carried across unchanged as a decimal. This is a point-in-time figure that reflects the value when the transfer ran; subsequent movements arrive through the sibling Update NCR Counterpoint Product Variant Inventory TO iPaaS.com collection.

Available quantity can legitimately be negative in NCR Counterpoint where commitments exceed stock on hand. The endpoint description records this field as a decimal and documents no floor at zero, so a negative figure is passed on as-is rather than being corrected in transit. Subscribers whose downstream systems cannot accept a negative availability should apply a formula that floors the value at zero rather than assuming it never occurs.

Source: QTY_ON_HND · Destination: QtyOnHand

This is a recommended field. The endpoint description for variant inventory does not list it as required, so iPaaS.com accepts an inventory record without it, but it should be mapped for any meaningful inventory sync.

The physical stock held for this variant at this location as recorded in NCR Counterpoint, carried across unchanged as a decimal. This differs from QtyAvailable in the same collection: on-hand is what is present, available is what is left once commitments are taken into account.

Source: return await AverageCostFromSettingsAsync(ITEM_NO); · Destination: Cost

This is an optional field. The endpoint description for variant inventory does not list it as required, and iPaaS.com accepts an inventory record without it.

This mapping needs more explanation than its product-level counterpart, because NCR Counterpoint does not cost variants individually. A gridded item carries one cost at the item level, not a separate cost per colour or size, and the variant inventory record the integration reads does not carry a cost of its own or a route back to the parent item's cost. Every variant of an item therefore reports the same cost, and that is a limitation of the source data rather than a mapping that could be improved.

The formula works around this by reading the cost from the item's inventory at the stocking location configured for the integration. It fetches the item's inventory records and returns the rolling average cost held at that one location.

Two consequences follow, and subscribers and their MiSP should be aware of both. The stocking location must be configured for the integration, and the item must actually hold an inventory record at that location — if it does not, the formula returns nothing and the variant inventory transfers with no cost. Because the field is optional, that is a silent gap rather than a failed transfer. And the cost reported against a variant is the cost at the stocking location, not at the location the inventory record itself describes. A variant whose stock sits at a location with a different average cost still reports the stocking location's figure.

Subscribers who do not want cost figures leaving Counterpoint, or for whom a single item-level cost applied to every variant is misleading, can remove this mapping; the inventory record still transfers without it.

Source: return await LocationIdFromNameAsync(LOC_ID); · Destination: LocationId

This is a required field — iPaaS.com rejects the inventory record without it, and the value must be a valid iPaaS.com location id.

NCR Counterpoint identifies its locations by name; iPaaS.com identifies them by id. The formula takes the Counterpoint location name from the variant inventory record and resolves it to the matching iPaaS.com location id.

The location named on the Counterpoint inventory record MUST exist as a location in iPaaS.com before the first transfer of variant inventory from that location. If it does not, the formula resolves to nothing and the transfer of that inventory record fails, because the location is required. This is a hard prerequisite, not a preference. Subscribers and their MiSP must do one of two things before enabling this collection: EITHER (a) transfer Counterpoint's locations to iPaaS.com so that a matching location exists for every location that holds stock, OR (b) create the locations in iPaaS.com by hand with names matching the Counterpoint location names. One of the two MUST be done at install time.

Locations are matched by name. Subscribers whose iPaaS.com locations are named differently from their Counterpoint locations should replace this mapping with a Lookup Translation that maps each Counterpoint location name to the correct iPaaS.com location.

Source:

Destination: ParentId

This is a required field — iPaaS.com rejects the inventory record without it, and the value must be greater than zero. It identifies the product variant the inventory belongs to.

The formula builds the variant's SKU from the item number and its grid dimensions, then looks that SKU up against the product variants already transferred into iPaaS.com and returns the matching variant's iPaaS.com id. The SKU is assembled exactly as described in the collection filter above: item number, first dimension, then the second and third dimensions only where they are in use. Because the filter performs the same lookup before any mapping in this collection runs, the product variant is known to exist by the time this formula evaluates, and the lookup succeeds.

Subscribers or their MiSP who change the SKU construction here must make the identical change in the collection filter. The two are separate pieces of the same rule, and if they disagree, records the filter admits will fail here for want of a parent.

This mapping appears only in this collection and not in the sibling Update NCR Counterpoint Product Variant Inventory TO iPaaS.com, because resolving the variant requires a lookup against iPaaS.com on every record and variant inventory changes far more often than variants do. The Update collection identifies the existing inventory record directly instead.

The value is supplied automatically by the lookup. Subscribers should not replace it with a fixed value — a hardcoded or zero variant id causes the transfer to be rejected.

Source: QTY_AVAIL · Destination: QtyAvailable

This is a recommended field. The endpoint description for variant inventory does not list it as required, so iPaaS.com accepts the update without it, but available quantity is the figure most downstream systems read to decide what can be sold, and keeping it current is the main reason this collection runs.

The quantity available for this variant at this location as NCR Counterpoint calculates it — on-hand stock less amounts already committed to orders. It is carried across unchanged as a decimal, and reflects the value at the moment the transfer ran.

Available quantity can legitimately be negative in NCR Counterpoint where commitments exceed stock on hand. The endpoint description records this field as a decimal and documents no floor at zero, so a negative figure is passed on as-is rather than being corrected in transit. Subscribers whose downstream systems cannot accept a negative availability should apply a formula that floors the value at zero rather than assuming it never occurs.

Source: QTY_ON_HND · Destination: QtyOnHand

This is a recommended field. The endpoint description for variant inventory does not list it as required, so iPaaS.com accepts the update without it, but it should be mapped for any meaningful inventory sync.

The physical stock held for this variant at this location as recorded in NCR Counterpoint, carried across unchanged as a decimal. This differs from QtyAvailable in the same collection: on-hand is what is present, available is what is left once commitments are taken into account.

Source: return await AverageCostFromSettingsAsync(ITEM_NO); · Destination: Cost

This is an optional field. The endpoint description for variant inventory does not list it as required, and iPaaS.com accepts the update without it.

This mapping needs more explanation than its product-level counterpart, because NCR Counterpoint does not cost variants individually. A gridded item carries one cost at the item level, not a separate cost per colour or size, and the variant inventory record the integration reads does not carry a cost of its own or a route back to the parent item's cost. Every variant of an item therefore reports the same cost, and that is a limitation of the source data rather than a mapping that could be improved.

The formula works around this by reading the cost from the item's inventory at the stocking location configured for the integration. It fetches the item's inventory records and returns the rolling average cost held at that one location.

Two consequences follow, and subscribers and their MiSP should be aware of both. The stocking location must be configured for the integration, and the item must actually hold an inventory record at that location — if it does not, the formula returns nothing and the update carries no cost. Because the field is optional, that is a silent gap rather than a failed transfer. And the cost reported against a variant is the cost at the stocking location, not at the location the inventory record itself describes. A variant whose stock sits at a location with a different average cost still reports the stocking location's figure.

Subscribers who do not want cost figures leaving Counterpoint, or for whom a single item-level cost applied to every variant is misleading, can remove this mapping; the update still transfers without it. Any such change should be made identically in the sibling Add NCR Counterpoint Product Variant Inventory TO iPaaS.com collection.

Source: return await LocationIdFromNameAsync(LOC_ID); · Destination: LocationId

This is a required field — iPaaS.com rejects the update without it, and the value must be a valid iPaaS.com location id.

An inventory record states how much stock exists at a particular place, so the place has to be identified on an update as well as on a create. NCR Counterpoint identifies its locations by name; iPaaS.com identifies them by id. The formula takes the Counterpoint location name from the variant inventory record and resolves it to the matching iPaaS.com location id.

The location named on the Counterpoint inventory record MUST exist as a location in iPaaS.com before the first transfer of variant inventory from that location. If it does not, the formula resolves to nothing and the transfer of that inventory record fails, because the location is required. This is a hard prerequisite, not a preference. Subscribers and their MiSP must do one of two things before enabling this collection: EITHER (a) transfer Counterpoint's locations to iPaaS.com so that a matching location exists for every location that holds stock, OR (b) create the locations in iPaaS.com by hand with names matching the Counterpoint location names. One of the two MUST be done at install time.

Locations are matched by name, so the names must correspond between the two systems. Subscribers whose iPaaS.com locations are named differently from their Counterpoint locations should replace this mapping with a Lookup Translation that maps each Counterpoint location name to the correct iPaaS.com location. Any such replacement should be made identically in the sibling Add NCR Counterpoint Product Variant Inventory TO iPaaS.com collection, so that updates resolve to the same location the record was created against.

Errors raised while transferring these records surface at Dashboard / Integration Monitoring / Error Logs. The specific messages, their causes and their resolutions are documented in NCR Counterpoint Error Messages. A record stopped by an error is not retried automatically; it must be resolved manually.

These and other runtime behaviors are documented in NCR Counterpoint Known Limitations.