Connection and Settings

Required Fields Checked Before Transfer

Counterpoint Rejections

Dynamic Formula Errors

Business Rules and Duplicates

Timecards

Internal Errors

Refunds

Description: The subscription has no address recorded for the Counterpoint API, so the integration has nowhere to send the transfer. Nothing reached Counterpoint.

Resolution: Set the Counterpoint API address in the subscription settings. See the Connections and Settings article for where the value comes from.

Description: The integration reached the Counterpoint API address but could not obtain an access token from it. The remainder of the message carries the reply the API gave to the connection attempt.

Resolution: Confirm the connection credentials are valid and that the Counterpoint API is running and reachable at the configured address.

Description: The integration reached the Counterpoint API but could not read the company record it needs before transferring anything. This usually means the connection is configured but not working — the credentials, the address, or the Counterpoint service itself. A companion message, Retrieved data from SY_COMP, but it appears invalid, means the company record was read but is not usable.

Resolution: Confirm the connection settings and that the Counterpoint API is running and reachable. If the connection is otherwise healthy and the companion message appears, your MiSP can investigate and involve iPaaS.com Support if needed.

Description: The integration could not resolve which Counterpoint connection this transfer should use. A companion form adds the external system id it was looking for, and a Dynamic Formula that needs to read from Counterpoint raises the same underlying problem worded Unable to retrieve Counterpoint Connection., prefixed with the formula that hit it.

Resolution: Confirm the Counterpoint connection exists on the subscription and is marked active. Where it is present and active, your MiSP can raise it with iPaaS.com Support, quoting the system id in the message.

Description: The integration's access token for the Counterpoint API had expired, and the attempt to obtain a new one also failed. The remainder of the message carries the reply the API gave to the renewal attempt.

Resolution: Confirm the credentials in the connection settings are still valid and that the Counterpoint API is reachable. Where the credentials have been changed in Counterpoint, update them on the iPaaS.com connection.

Description: A quantity mapping is using the quantity-from-settings formula, but the subscription has no quantity method chosen, so the formula does not know which quantity figure to report.

Resolution: Set the inventory quantity method in the subscription settings, as the message says. Alternatively, replace the mapping with one that reports the quantity figure directly.

Description: The chosen quantity method needs a location to report stock for, and none is set.

Resolution: Set the inventory location in the subscription settings. The location must be one configured in your own Counterpoint installation.

Description: The inventory quantity method setting names a quantity field that does not exist on the Counterpoint inventory table, so no figure can be read.

Resolution: Correct the inventory quantity method setting so it names a quantity field your Counterpoint installation actually holds. The Connections and Settings article lists the values this setting accepts.

Description: This is the largest single family of errors and the one most often misread. Despite the wording, these are raised by the integration before anything is sent to Counterpoint — Counterpoint never saw the record. These particular fields form part of the address the integration uses to reach the record; without them the call cannot be built at all. A small number are worded Attempt to get rather than Attempt to update, meaning the field was missing when reading an existing record rather than when writing one. Each record type checks the fields that identify it — for example a Customer Ship-To Address needs SHIP_ADRS_ID, an Item Inventory record needs ITEM_NO and LOC_ID, and a Timecard needs STR_ID and USR_ID.

Resolution: Map the named field on the collection that raised the error, or confirm the mapping already there is producing a value rather than an empty one. Each collection's mapping notes state which fields identify the record and what supplies them. Where the missing field is one the integration derives from a parent record — an ITEM_NO on a grid dimension, for example — check that the parent transferred successfully first; an earlier failure in the log on the same product is usually the real cause. Where the record type named in the message disagrees with the collection the error appeared on, trust the collection.

Description: Counterpoint refused the call and returned a reason. Counterpoint applies several families of check at transfer time, and any of them can appear here: a value too long for the field ([Field] ([TABLE].[COLUMN]) is [n] characters long but has a maximum length of [max]); a required field left empty (Field is a required field.); a value not present in its lookup (Field has a value that is not present in its lookup: [value]); or a value of the wrong data type ([Field] is not a valid T_BOOL, or …contains time. It should contain only the date.). The same code also covers Counterpoint's refusals when creating a record — a missing template customer, an (AUTO-ASSIGN) workgroup that cannot be found or has no next number, or Name is required for addresses with a Business name type — and gift-card refusals such as Gift Card Number is required or Unable to load gift card [number].

Resolution: Read the innermost message to see which value Counterpoint rejected, then correct it at source or in the mapping — shorten a value that is too long, supply a missing required value, use a value that exists in your Counterpoint installation's lookup, or produce Y/N for a yes/no field. For a create-time refusal, confirm the workgroup, its template customer and its next-number setting exist in Counterpoint. Where the cause is unclear, your MiSP can investigate and involve iPaaS.com Support if needed. Because this check runs only on values that changed in this transfer, a bad value already sitting on a record is never re-reported — verify suspect reference data in Counterpoint directly.

Description: A unit-of-measure formula was asked for an item Counterpoint does not hold. Products are not transferred automatically as a prerequisite, so this usually means the product has not reached Counterpoint.

Resolution: Transfer the product to Counterpoint before the record that refers to it. Where products are expected to already be there, confirm the item number the formula is reading is the one Counterpoint uses.

Description: The formula that resolves a unit of measure recognises a fixed set of unit positions and was given something outside it.

Resolution: Confirm the item's unit configuration in Counterpoint. Where the formula has been edited, confirm it is passing a unit position the formula handles.

Description: The item exists, but the unit of measure asked for is not one of the units configured against it.

Resolution: Confirm the unit is configured on the item in Counterpoint, or that the formula is asking for a unit the item actually has.

Description: A refund line must be linked back to the line of the original sale it reverses, and the link could not be made. The reason names which step failed — the original order was not specified or not found, its line could not be located by id, it has no external id for this system, its external id is not in the expected DOC_ID|LIN_SEQ_NO format, or no acceptable release line remains.

Resolution: Confirm the original sale has been transferred to Counterpoint and that the refund refers to it. Where the reason mentions an external id that is not in the expected format, the link between the iPaaS.com order line and its Counterpoint counterpart is malformed — your MiSP can raise it with iPaaS.com Support, quoting the value shown. Where the reason mentions no acceptable release line found, the quantity being returned may already have been returned; confirm the return is valid against what remains on the original order.

Description: A grid-dimension formula was given a dimension position outside the three Counterpoint supports.

Resolution: Correct the formula so the dimension position is 1, 2 or 3.

Description: A lookup formula was asked for a Counterpoint field that does not exist on the table it is reading. This is a formula error rather than a data problem. The message also appears in a longer form prefixed with the lookup that raised it, and, for the item table, as The table IM_ITEM does not include the field ….

Resolution: Correct the field name in the formula, and confirm the field exists on the Counterpoint table the formula is reading. In the lookup-table form, the field named is the one the formula was asked to return.

Description: A lookup formula expected at most one row per item and found several, so it could not decide which value to return. A longer form adds the table and field it was reading. This usually means the match conditions in the formula are not specific enough for the table being read.

Resolution: Add match conditions to the formula so it identifies a single row — commonly a location, a grid dimension, or a sequence number. Where the duplicate rows are unexpected, check the item in Counterpoint for records that should not be there.

Description: A lookup formula was called without all the values it needs. Companion messages cover the variant equivalent (VariantMapTableLookup requires …) and a second lookup started without all three of its arguments (Secondary lookup requires secondaryMatches, secondaryTableName, and secondaryFieldName).

Resolution: Supply the missing arguments in the formula. Where a secondary lookup is not wanted, remove all three of its arguments rather than some of them.

Description: The formula is supplying a value the integration inserts for you, so the value collides with the one being added. There are four forms, covering child items and variants and the primary and secondary match lists.

Resolution: Remove the item number — and, for variants, the grid dimensions — from the match list the message names. The integration adds them itself as it walks each child or variant.

Description: A formula that reads a custom field was pointed at something that does not carry custom fields — commonly a single field value where the whole record was intended, or a parent record where a line was intended.

Resolution: Correct the formula so it reads the custom field from the record itself rather than from one of its values. Compare it against a working custom-field mapping on another collection in the same template.

Description: The address mapping carries the duplicate-prevention option, and an address already on the customer matched every value being supplied. The address was not added. This is the option working as intended, not a fault — it is reported as an error only because that is the mechanism available to stop the transfer.

Resolution: No action is needed where the duplicate is genuine. Where addresses that differ are being blocked, review the values the mapping supplies — the match is made across the whole address, so two addresses are treated as duplicates only when every mapped value agrees. To allow duplicates, remove the duplicate-prevention option from the mapping.

Description: A customer arriving from Counterpoint matched an existing iPaaS.com customer by email address, but the link between the two could not be created, so the same person may end up on two iPaaS.com records.

Resolution: Check iPaaS.com for a duplicate of the customer named in the surrounding log entries. Your MiSP can reconcile the records and, if the link keeps failing, raise it with iPaaS.com Support.

Description: A kit's transfer also transfers the products it is built from, and one of them failed; the kit does not transfer without them. A companion message, Kit parent or component SKU {sku} could not be retrieved, means the product could not be read from iPaaS.com at all.

Resolution: Look for an earlier error in the log for the named SKU — that error is the actual cause. Resolve it and transfer the kit again. Where the message says the SKU could not be retrieved, confirm the product exists in iPaaS.com and that the kit refers to the SKU it actually uses.

Description: A timecard line is identified by its store, user, date and a sequence number, and the sequence number supplied was not a whole number. The record could not be located or written.

Resolution: Correct the mapping so the sequence number is a whole number. Where the identifier is being assembled from several parts, confirm the parts are in the expected order and that none is empty.

Description: The integration could not work out how to identify the record it was given, or could not read a value from it during translation. Related forms include Unable to determine primary key…, Invalid data passed to [record].SetPrimaryKey…, and Unable to GetValue from source object…. These indicate a fault in the integration rather than anything a subscriber can configure. Where this appears on a collection whose records are identified by several values joined together, an altered identifier mapping is a common trigger.

Resolution: Confirm the mapping supplying the record's identifier has not been altered. If it is intact, your MiSP can raise it with iPaaS.com Support, quoting the message and the transaction it appeared on — there is no subscriber-side configuration that resolves these.

Description: Both refund collections stop the transfer when the refund's first payment carries a status of Declined. A refund whose payment was declined has not returned any money, so writing it to Counterpoint would record a refund that did not happen.

Resolution: No action is needed for a genuinely declined refund — the filter is doing its job. Where a refund was expected to succeed, investigate the payment in the source system.

Description: As shipped, this collection returns a deposit in full and nothing less. A refund whose amount does not equal the total of the order it is written against — a partial deposit refund — is stopped rather than written to Counterpoint as a smaller amount.

Resolution: Handle partial deposit refunds in Counterpoint directly. This condition is editable by subscribers or their MiSP on the collection alongside the declined-payment condition, so it can be relaxed if partial deposit refunds should transfer. Do not change it without validating the result in a staging environment first — a partial amount written against a deposit does not necessarily reconcile the way a full return does, and the consequences appear in Counterpoint rather than in the error log.

NCR Counterpoint Connections and Settings

NCR Counterpoint Installation Instructions

NCR Counterpoint Known Limitations