This mapping collection brings product kits from NCR Counterpoint into iPaaS.com. A kit describes how an existing product is composed from other products: it carries the kit parent's SKU and the kit's classification, and it drives the component lines that say which items the kit contains and in what quantity.

Deletions are carried by the Delete NCR Counterpoint Product Kit TO iPaaS.com collection: when the record is removed in Counterpoint, that collection sends the removal to iPaaS.com. Whether the removal transfers automatically depends on the delete trigger event being available; where it is not, the collection runs through Manual Sync. See NCR Counterpoint Known Limitations.

Source: ITEM_NO · Destination: Sku

This is a required field — iPaaS.com rejects the kit without it. The item number of the kit parent in NCR Counterpoint, which is what identifies the kit in both systems. NCR Counterpoint stores this as text of up to 20 characters and always populates it.

The kit parent must also exist in iPaaS.com as a product in its own right, carrying this same SKU — a kit in iPaaS.com describes how an existing product is composed, it does not create that product. The integration handles this automatically: when a kit transfer is detected, it checks that every component item and the kit parent item have already been transferred to iPaaS.com, and transfers any that are missing before the kit itself. Subscribers and their MiSP do not need to sequence those transfers by hand or add a filter to hold the kit back. If a component or the kit parent cannot be retrieved from NCR Counterpoint at all, the kit transfer fails rather than transferring an incomplete kit.

Changes to a kit parent in NCR Counterpoint are queued rather than sent immediately, so kit transfers are asynchronous. A change made in Counterpoint appears in iPaaS.com shortly afterwards rather than instantly, and subscribers should allow for that delay when verifying a change rather than treating the gap as a failure.

Component expansion is supported for Misc kits used on orders. Kits of other types transfer as item numbers only — the kit record is created, but the integration does not expand it into its constituent components on an order.

Source: Static value —Basic` · Destination: Type

This is a required field — iPaaS.com rejects the kit without it. Allowed values: Bill of Material, Basic, and Add-on.

Every kit transferred by this collection is recorded in iPaaS.com as Basic. This is a fixed value rather than one read from NCR Counterpoint, because Counterpoint does not carry a kit classification that maps onto the three values iPaaS.com recognizes. Basic is a genuine allowed value and the appropriate default for Counterpoint kits — it is not a stand-in to be replaced at implementation time.

Subscribers whose downstream systems need to distinguish kit types can replace this Static with a formula or a Lookup Translation that derives the type from the kit parent record. Any replacement must resolve to one of the three allowed values above; a value outside that set causes the transfer to fail.

Parent: Add/Update NCR Counterpoint Product Kit TO iPaaS.com.

Source: COMP_ITEM_NO · Destination: Sku

This is a required field — iPaaS.com rejects the component without it. The item number of the component item in NCR Counterpoint, which identifies which product this line of the kit is made of.

A component SKU must not appear twice within the same kit. NCR Counterpoint records each component of a kit once, so this is satisfied by the source data as it stands; subscribers replacing this mapping with a formula that could produce the same SKU on two lines of one kit would cause the kit transfer to fail.

Each component product must exist in iPaaS.com before the kit that references it can be created. The parent collection handles this automatically, transferring any missing component products before the kit itself, so subscribers and their MiSP do not need to sequence this by hand.

Components must be ordinary products. Gridded items — the Counterpoint items that transfer to iPaaS.com as product variants — are not supported as kit components, and the kit inventory functions that other integrations use to derive a kit parent's stock level from its components do not handle them.

When a kit is updated, iPaaS.com replaces the component list with what the update supplies. Any component that is not included in the update is removed from the kit automatically, so no separate removal mapping is needed. One limitation applies: the last remaining component of a kit cannot be removed this way. A kit can be reduced to a single component, but that final component cannot be dropped by an update, and subscribers who need the kit gone should remove the kit itself rather than emptying it.

Source: COMP_QTY · Destination: Quantity

This is a recommended field. The endpoint description for kits does not list a quantity on a component as required, so iPaaS.com accepts a component without one — but a kit component with no quantity does not describe how much of the item the kit contains, so it should be mapped for any meaningful kit sync. The number of the component item that the kit contains, read from NCR Counterpoint and carried across unchanged. It is a decimal value, so components measured in fractional amounts transfer as recorded.

How this quantity should be read depends on the Type mapping in this collection, which decides whether the number is a fixed amount per kit or an amount per unit of the kit sold. The unit the quantity is counted in is decided by the Unit mapping.

Negative component quantities are not supported. Where one is present, the kit inventory functions that other integrations use to derive a kit parent's stock level treat the component as zero rather than subtracting from the total.

Source:

Destination: Unit

This is a required field — iPaaS.com rejects the component without it. The value must be a valid unit name for the component SKU, not a unit id, and the unit must be one that exists against that product in iPaaS.com.

NCR Counterpoint does not record the unit name on the kit component line. It records a flag indicating which of the component item's units the quantity is counted in, and the unit names themselves live on the component item's own record. The formula therefore reads the component item's record and returns the unit name that the flag points at: the item's stocking unit when the flag is zero, or the item's first through fifth alternate unit for flag values one through five respectively.

This means the component item's units must be transferring to iPaaS.com correctly for the kit to transfer. If the component item does not carry the alternate unit that its kit line points at, the formula returns nothing for that component and the kit transfer fails, because the unit is required.

A gap is worth knowing about: the formula covers flag values zero through five and has no fallback branch. A component whose flag holds any other value produces no unit at all rather than defaulting to the stocking unit, and the kit transfer fails. NCR Counterpoint's own maintenance screens do not offer values outside that range, so this is unlikely to arise from ordinary data entry, but subscribers or their MiSP investigating a kit that will not transfer with a unit error should check the component line's unit flag first.

Source:

Destination: Type

This is an optional field. The endpoint description for kits lists the allowed values for a component type but does not mark it required, so iPaaS.com accepts a component without one. Allowed values: Fixed and Per Parent Quantity.

This mapping records how the component's quantity should be interpreted. The formula reads the component's quantity method in NCR Counterpoint. When that method is F, the mapping produces Fixed, meaning the kit contains that quantity of the component regardless of how many of the kit are sold. Every other value produces Per Parent Quantity, meaning the quantity is multiplied by the number of kits.

Note that the fallback is unconditional: Per Parent Quantity is the result for anything that is not exactly F, including an empty quantity method. Subscribers who need a different default should replace the formula, and any replacement must resolve to one of the two allowed values above.

Parent: Add/Update NCR Counterpoint Product Kit TO iPaaS.com.

Mapping Filter

Filter Description.

This collection runs only when the source being evaluated is the kit parent record rather than a component line, and only when the kit parent is flagged in NCR Counterpoint as including the parent item. Because the filter tests that flag for exactly the value Y, a kit whose flag is empty or holds anything else is treated as not including the parent.

A kit that does not carry the flag produces no rows from this collection at all, which is the correct outcome — the kit still transfers, with only its ordinary component lines. Subscribers or their MiSP editing this filter should keep both conditions in place: relaxing either one would add a kit parent line to kits that do not include their parent.

Source: Parent.ITEM_NO · Destination: Sku

This is a required field — iPaaS.com rejects the component without it.

This collection exists to handle one specific case: a kit whose own parent item is itself one of the things the kit contains. NCR Counterpoint records that with a flag on the kit parent indicating the parent item is included. Where the sibling collection Add/Update NCR Counterpoint Product Kit Component TO iPaaS.com transfers the ordinary component lines of a kit, this collection adds one extra component line for the kit parent item itself.

The collection filter is what confines it to that case. It runs only when the source being evaluated is the kit parent record rather than a component line, and only when the kit parent is flagged in NCR Counterpoint as including the parent item. A kit that does not carry that flag produces no rows from this collection at all, which is the correct outcome — the kit still transfers, with only its ordinary component lines. Because the filter tests the flag for exactly the value Y, a kit whose flag is empty or holds anything else is treated as not including the parent.

The SKU here is the kit parent's own item number, read from the parent record — the same value the parent collection sends as the kit's SKU. A component SKU must not appear twice within one kit, so a kit that is flagged to include its parent and also lists that same item as an ordinary component would produce a duplicate and fail to transfer.

Source: Static value —1` · Destination: Quantity

This is a recommended field. The endpoint description for kits does not list a quantity on a component as required, so iPaaS.com accepts a component without one, but a component with no quantity does not describe how much of the item the kit contains.

The kit parent is always included exactly once, so this is a fixed value of one rather than a number read from NCR Counterpoint. Counterpoint's include-parent flag records only whether the parent is included, not how many of it — so there is no source value to read here, and one is the only quantity the flag can mean. This is a genuine constant, not a stand-in to be replaced at implementation time.

Source:

Destination: Unit

This is a required field — iPaaS.com rejects the component without it. The value must be a valid unit name for the SKU, not a unit id, and the unit must be one that exists against that product in iPaaS.com.

The formula reads the kit parent item's own record and returns its stocking unit. Unlike the equivalent mapping in Add/Update NCR Counterpoint Product Kit Component TO iPaaS.com, there is no unit flag to consult — Counterpoint's include-parent flag carries no unit of its own — so the stocking unit is used unconditionally. There is no alternate-unit branch and no fallback.

The kit parent item must therefore have a stocking unit recorded in NCR Counterpoint and must be transferring to iPaaS.com with that unit. If it does not, this mapping returns nothing and the kit transfer fails, because the unit is required.

Source: Static value —Fixed` · Destination: Type

This is an optional field. The endpoint description for kits lists the allowed values for a component type but does not mark it required. Allowed values: Fixed and Per Parent Quantity.

The kit parent line is always recorded as Fixed, meaning the kit contains one of the parent item regardless of how many of the kit are sold. This pairs with the Quantity mapping in this collection: the two together state that the parent item is included exactly once per kit. Fixed is a genuine allowed value and the only one consistent with that meaning — it is not a stand-in to be replaced at implementation time.

This collection carries no mapped fields. iPaaS.com matches the record by the external ID recorded when it first transferred, so a removal needs no field mapping.

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.

At the time this documentation was written:

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