NCR Counterpoint to iPaaS.com Product Inventory Mapping Documentation

This mapping collection brings a product's stock figures from NCR Counterpoint into iPaaS.com for the first time, creating the inventory record that ties a product to the location its stock sits at. It carries the quantity available, the quantity on hand, the average cost at that location, the location itself, and the link to the product 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 inventory records. This collection and Update NCR Counterpoint Product 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 Inventory TO iPaaS.com reaches the same records by a different route, as part of a product 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 products are also maintained in another connected system.

Mapping Filter

Filter Description.

The filter takes the Counterpoint item number from the inventory record and looks it up against the products already transferred into iPaaS.com. Where no matching product 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 effect is that this collection creates inventory only for products iPaaS.com already knows about. The product link this collection needs is resolved by the same lookup, so subscribers or their MiSP who widen or remove this filter should be aware that records admitted without a matching product have no product to attach to.

Source: QTY_AVAIL · Destination: QtyAvailable

This is a recommended field. The endpoint description for 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 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, not a live one; subsequent movements arrive through the sibling Update NCR Counterpoint Product 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 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 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. Subscribers should map both where downstream systems need to distinguish physical stock from sellable stock.

Source: AVG_COST · Destination: Cost

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

NCR Counterpoint's rolling average cost for the item at this location, carried across unchanged as a decimal. Counterpoint recalculates this figure as stock is received, so it reflects a blended cost across receipts rather than the price paid on any single purchase order.

Subscribers who cost their inventory on a different basis should replace this mapping with the source that matches their accounting practice. Subscribers who do not want cost figures leaving Counterpoint at all can remove the 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.

An inventory record states how much stock exists at a particular place, so the place has to be identified. NCR Counterpoint identifies its locations by name; iPaaS.com identifies them by id. The formula bridges that by taking the Counterpoint location name from the inventory record and resolving 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 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, rather than renaming records in either system.

Source: return await GetSpaceportIdAsync(ITEM_NO, "Product", SpaceportSystemId); · 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 the inventory belongs to.

The formula takes the Counterpoint item number and looks up the matching product already transferred into iPaaS.com, returning that product's iPaaS.com id. This is the same lookup the collection filter performs, which is why the two always agree: the filter has already established that the product exists before any mapping in this collection runs, so by the time this formula evaluates, the lookup succeeds.

This mapping appears only in this collection and not in the sibling Update NCR Counterpoint Product Inventory TO iPaaS.com. The reason is cost. Resolving the product requires a lookup against iPaaS.com on every inventory record, and inventory typically changes far more often than products do. Paying that lookup is acceptable when an inventory record is first created, which happens once per product and location; paying it on every quantity change is not. The Update collection instead identifies the existing inventory record directly, so it does not need to resolve the product again.

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

Source: QTY_AVAIL · Destination: QtyAvailable

This is a recommended field. The endpoint description for 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 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 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 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. Subscribers should map both where downstream systems need to distinguish physical stock from sellable stock.

Source: AVG_COST · Destination: Cost

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

NCR Counterpoint's rolling average cost for the item at this location, carried across unchanged as a decimal. Counterpoint recalculates this figure as stock is received, so it reflects a blended cost across receipts rather than the price paid on any single purchase order. Because this collection runs on inventory movements, the cost is refreshed as those movements occur.

Subscribers who cost their inventory on a different basis should replace this mapping with the source that matches their accounting practice, and should make the same change in the sibling Add NCR Counterpoint Product Inventory TO iPaaS.com collection so that a record's cost does not change basis between creation and its first update. Subscribers who do not want cost figures leaving Counterpoint at all can remove the mapping from both collections; the inventory record still transfers without it.

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 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 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, rather than renaming records in either system. Any such replacement should be made identically in the sibling Add NCR Counterpoint Product 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.