NCR Counterpoint Known Limitations

The NCR Counterpoint integration synchronizes products, inventory, customers, gift cards, orders, sale tickets, refunds, timesheets and reference data between NCR Counterpoint and iPaaS.com. This article sets out what it does not do, what it does not check, and what subscribers or their MiSP must decide or configure before relying on it.

Everything below was true at the time this documentation was written.

This is the limitation most likely to cost time, because it cuts both ways.

Counterpoint checks many of the values a transfer supplies and refuses the ones it will not accept. A refused value comes back as a transfer error at Dashboard / Integration Monitoring / Error Logs, naming the field and the value. Subscribers should expect to meet these, particularly while a new installation is being configured — they are a normal part of getting a set of mappings right.

That checking is not applied uniformly to every field. Whether a particular field is verified against a list of permitted values is a property of the Counterpoint installation's own data dictionary, not something this integration sets, controls, or can report on. The practical consequence is that a value which is wrong for your installation may be refused at transfer time — or may be accepted and written to the record.

Where a value is accepted without being checked, the problem surfaces later — when the record is posted, or when another Counterpoint function reads it — a long way from the transfer that caused it. It will not look like an integration error when it does.

Consequences worth planning for:

Many Counterpoint fields are text of a fixed length. Where a mapped value is longer than the field allows, the value is shortened to fit before it is saved and the transfer succeeds. The trimmed part is not recorded anywhere, and nothing is reported.

Where a field matters in full — a name, a description, a comment — confirm the source values fit the length Counterpoint allows. The mapping notes state the length wherever it constrains a field.

This is the most common reason a record that exists in Counterpoint never appears in iPaaS.com, and because nothing is refused, nothing is logged when it happens.

As delivered, the integration is filtered to the records Counterpoint flags for e-commerce. A record failing the test simply never raises a notification, so there is no error to find.

The filtering is applied in two independent places, and the two are not the same test:

Because the two layers test different things, widening one does not widen the other. A customer without an email address is stopped Counterpoint-side whatever the iPaaS.com filter says.

This is a shipped default, not a limit of the integration. Subscribers whose business needs a wider set — every customer rather than the e-commerce ones, for example — can widen both filters. Subscribers or their MiSP should decide which records are in scope before enabling the collections, and confirm in a staging environment that the set arriving is the set expected.

Add NCR Counterpoint Sale Ticket FROM iPaaS.com and Add/Update NCR Counterpoint Sale Ticket TO iPaaS.com ship with a mapping filter that matches no record, so neither transfers anything as delivered. Each collection's description states exactly what to remove to enable it.

Enabling a trigger subscription does not change this. While the filter blocks every record, nothing transfers through the collection — including a Manual Sync — no matter which subscriptions are enabled.

Orders reaching Counterpoint can be written either as orders or as sale tickets, and the integration ships collections for both. They are alternatives, not complements — running both writes the same source transaction twice.

Subscribers or their MiSP should decide which path their business uses and disable the other. The Add NCR Counterpoint Order FROM iPaaS.com family and the Add NCR Counterpoint Sale Ticket FROM iPaaS.com family carry the same guidance in their descriptions, along with the two order-update collections that follow the order path.

A number of features raise their Counterpoint notifications only after a step has been taken against the Counterpoint database. Until that step is done, records for those features reach iPaaS.com only through Manual Sync — nothing transfers on its own, and there is no setting in the iPaaS.com portal that changes it. They fall into two groups.

Shipped, but switched off. Product Kit, Location Group and Product Category Assignment are installed by the standard database installer already, with their trigger events recorded as not subscribed. Both the add/update and the delete side are switched off, so neither additions nor removals flow as installed. Enabling one is a matter of switching its events on — nothing needs to be created.

Not installed by the standard installer. Product Barcode Type, Product Substitute Item, User, Timesheet and Message need their trigger and subscription records added.

Scripts for both groups are supplied per feature in the optional-scripts folder of the install repository. Do not use the scripts published in older feature documentation for the shipped-but-switched-off features — those predate the installer, and re-running them duplicates the trigger event records and fails, because the database trigger already exists. Follow the Installation Instructions, which state which script applies to which case.

None of this is a capability the integration lacks. Every feature listed here has working collections; what is missing is the Counterpoint-side event that wakes them.

Trigger subscriptions live in the Counterpoint database and can be added or removed there directly. When that happens, the iPaaS.com portal can continue to display a subscription as active that the database no longer has, or miss one that it does.

The portal is therefore not a reliable mirror of what Counterpoint will actually raise. Where a feature is not transferring and the portal shows its subscription enabled, the Counterpoint-side configuration is the thing to check.

A trigger subscription can carry a filter query that narrows which records raise a notification. These can only be applied manually, on the Counterpoint side — they cannot be added or edited from the iPaaS.com portal.

Subscribers should treat this as a task for their MiSP. A mistake in the SQL a trigger calls can break saving records in Counterpoint, so the cost of getting it wrong is not confined to the integration.

Initialization performs a bulk load of an entity's existing Counterpoint records into iPaaS.com, and it is available for the reference entities that offer it: Location, Location Group, Shipping Method, Payment Method, Customer Category, Product Category and Alternate ID Type.

It is not offered for products, customers, inventory, or any transaction type. There is no bulk initial load for those, so a first load of catalogue and transactional data is performed by transferring records through the collections themselves — in the order described under Records are not transferred as prerequisites below, since a transaction referring to a customer or product that has not yet reached Counterpoint will not pull it across.

The order of a first load therefore matters. Each collection's description states what it does and does not pull across.

Stock quantities, costs and serial number lists describe the moment of transfer. The integration does not reconcile them afterwards, and there is no automatic retry or backfill for a record whose transfer failed.

A quantity in iPaaS.com is the quantity as at its last transfer, not a live figure. Where a value in Counterpoint changes without raising a notification the integration is subscribed to, iPaaS.com is not told.

When the integration updates an existing Counterpoint record, it preserves the fields it does not map — those keep whatever value Counterpoint currently holds. Every field the update does carry is written over the current value.

The risk is timing. Counterpoint is a live system, and between the original transfer and a later update, point-of-sale activity or staff may have changed the same record. Any field the update carries — even one the subscriber did not intend to change — overwrites Counterpoint's current value with the one the integration last sent, which may by then be out of date.

For this reason an update collection should map only the fields it genuinely needs to change. An order update limited to a status field, for example, changes the status and leaves the rest of the order in Counterpoint untouched, rather than rewriting the whole order with values that may no longer match what Counterpoint holds.

The order, item refund and deposit ticket tax collections carry a mapping filter that selects the transaction's aggregate tax row rather than its per-authority rows. A transaction whose tax Counterpoint splits across more than one authority therefore transfers with a single authority and the full tax amount, rather than split.

This is a shipped default, not a limit of the integration. The filter is subscriber-editable, and each collection's description states what its filter matches. Subscribers who need tax split by authority can widen it, and should validate the change in a staging environment first.

Separately, the shipped tax code, authority and rule formulas are written as a decision between three tax situations but supply the same value in every branch, so the test has no effect until a subscriber differentiates them. That structure is a starting point to be filled in, not a working configuration.

Where a refund cannot be written, the transfer raises an error rather than writing a partial or incorrect record. These errors surface at Dashboard / Integration Monitoring / Error Logs, and — like any transfer stopped by an error filter — must be resolved manually. The integration does not retry them automatically, so a record left in error stays in error until a subscriber or their MiSP acts on it.

Individual collections carry limitations that matter only in their own context — how a particular figure is derived, which of two fields wins, what a fixed value means for reporting. These are documented on the collection itself, in its description and mapping notes, where a subscriber configuring that collection will read them.

Two are worth naming here because they surprise people:

The default template is aligned to a demonstration pairing so that the integration works out of the box in a demo. That is intentional and correct in that context — it also means a real subscriber is not the demonstration.

67 mapped values across 21 collections are examples rather than Counterpoint defaults. Each is called out inline in its own mapping note with the marker Placeholder value — replace during implementation, which states what it is and what to replace it with.

Many of these are not refused at transfer time. Whether a particular value is checked varies by field, so an unreplaced example value may well be accepted and stored, with the problem appearing later. That is what makes this list worth working through before go-live rather than after.

The collections carrying them:

This article lists sixteen limitations, together with the placeholder values that must be replaced before go-live. Limitations that apply to a single collection are documented on that collection, in its description and mapping notes.