iPaaS.com to NCR Counterpoint Customer Mapping Documentation

This mapping collection writes customers from iPaaS.com into NCR Counterpoint. A customer that Counterpoint does not yet hold is created; one it already holds is updated. The collection carries the customer's name, their email address, the address Counterpoint keeps directly on the customer record, and the flag marking them as an e-commerce customer.

Outbound delete into Counterpoint is not supported. No delete behavior is implemented for this entity, delete mappings are not included in the default template, and removing a record in the source system does not delete the corresponding Counterpoint record. Records are moved on through their normal update path rather than deleted.

Source: Truncate( ( IsEmpty(Company) ? (FirstName + " " + LastName) : Company) ,40) · Destination: NAM

This is a required field — NCR Counterpoint rejects the customer without it. The customer's name as Counterpoint displays it. Counterpoint holds a single name for a customer rather than separate business and personal names, so the formula decides which to supply. When the iPaaS.com customer has a company, the company is used and the customer is treated as a business. When the customer has no company, the first and last names are joined with a space and the customer is treated as a person. This mapping works together with CUST_NAM_TYP below, which records which of the two styles was used — the two are derived from the same test so that they always agree.

Counterpoint stores this as text of up to 40 characters, and the formula trims the result to 40 so that longer names are shortened to fit rather than arriving over-length. Subscribers replacing this mapping should keep the trim.

A customer with no company, no first name and no last name produces a name consisting of a single space. Counterpoint accepts that, so the customer is created with an effectively blank name rather than being rejected. Subscribers whose iPaaS.com records may be missing all three values should replace this mapping with a formula that supplies a fallback.

Source: (IsEmpty(Company) ? "P" : "B") · Destination: CUST_NAM_TYP

This is a recommended field. Allowed values: B for a business and P for a person; Counterpoint accepts nothing else. Records which naming style the NAM value above uses, so that Counterpoint formats and searches the name correctly. The formula applies the same test as NAM: a customer with a company is marked as a business, and a customer without one is marked as a person. Keeping both mappings derived from the same test is what stops a person's name being stored under the business style, or the reverse.

Counterpoint supplies B of its own accord when nothing is mapped here, so a customer still transfers if this mapping is removed — but every customer would then be recorded as a business regardless of the name actually stored. Subscribers replacing this mapping should keep it derived from the same source as NAM.

Source: Truncate(GetValue(FirstMatch(Addresses, "IsPrimaryBilling == true"), "Address1"),40) · Destination: ADRS_1

This is an optional field. The first line of the customer's address. Counterpoint keeps one address directly on the customer record, so the formula takes the first iPaaS.com address flagged as the primary billing address and uses that. A customer with no address flagged as primary billing transfers with this field empty.

Counterpoint stores this as text of up to 40 characters, and the formula trims the value to 40 so that longer address lines are shortened to fit. The addresses that are not the primary billing address are handled separately by Add NCR Counterpoint Customer Ship-To Address FROM iPaaS.com.

Source: Truncate(GetValue(FirstMatch(Addresses, "IsPrimaryBilling == true"), "Address2"),40) · Destination: ADRS_2

This is an optional field. The second line of the customer's address, taken from the same primary billing address as ADRS_1 above. A customer with no address flagged as primary billing, or whose primary billing address has no second line, transfers with this field empty. Counterpoint stores this as text of up to 40 characters, and the formula trims the value to 40 so that longer address lines are shortened to fit.

Source: Truncate(GetValue(FirstMatch(Addresses, "IsPrimaryBilling == true"), "Address3"),40) · Destination: ADRS_3

This is an optional field. The third line of the customer's address, taken from the same primary billing address as ADRS_1 above. A customer with no address flagged as primary billing, or whose primary billing address has no third line, transfers with this field empty. Counterpoint stores this as text of up to 40 characters, and the formula trims the value to 40 so that longer address lines are shortened to fit.

Source: Truncate(GetValue(FirstMatch(Addresses, "IsPrimaryBilling == true"), "City"),20) · Destination: CITY

This is an optional field. The city of the customer's address, taken from the same primary billing address as ADRS_1 above. Counterpoint stores this as text of up to 20 characters — noticeably shorter than the address lines — and the formula trims the value to 20 so that longer city names are shortened to fit. Subscribers whose city names commonly exceed 20 characters should be aware that the stored value is the shortened form.

Source: Truncate(GetValue(FirstMatch(Addresses, "IsPrimaryBilling == true"), "Country"),20) · Destination: CNTRY

This is an optional field. The country of the customer's address, taken from the same primary billing address as ADRS_1 above. Counterpoint stores this as free text of up to 20 characters rather than a fixed list of country codes, and the formula trims the value to 20 so that longer country names are shortened to fit. Whatever form iPaaS.com holds the country in is what Counterpoint receives, so subscribers who need a particular form — full names rather than two-letter codes, for example — should confirm that iPaaS.com supplies it consistently, or replace this mapping with a formula that converts it.

Source: Truncate(GetValue(FirstMatch(Addresses, "IsPrimaryBilling == true"), "Region"),10) · Destination: STATE

This is an optional field. The state, province or region of the customer's address, taken from the same primary billing address as ADRS_1 above. Counterpoint stores this as free text of up to 10 characters, and the formula trims the value to 10 so that longer region names are shortened to fit. Because 10 characters is short, subscribers whose iPaaS.com records hold full region names rather than abbreviations should expect the stored value to be the shortened form, and should replace this mapping with a formula that converts full names to the abbreviations their Counterpoint installation expects.

Source: Truncate(GetValue(FirstMatch(Addresses, "IsPrimaryBilling == true"), "PostalCode"),15) · Destination: ZIP_COD

This is an optional field. The postal code of the customer's address, taken from the same primary billing address as ADRS_1 above. Counterpoint stores this as free text of up to 15 characters, which accommodates the postal code formats in normal use, and the formula trims the value to 15 so that anything longer is shortened to fit.

Source: "Y" · Destination: IS_ECOMM_CUST

This is a recommended field. Allowed values: Y and N; Counterpoint accepts nothing else. Marks the customer as an e-commerce customer in Counterpoint. Every customer arriving from iPaaS.com is marked Y, which is correct for this integration — these customers originate online. This is a genuine Counterpoint flag rather than an example value, so it does not need changing for a typical install.

This flag is not only descriptive. The CUST_NO mapping below matches incoming customers against existing Counterpoint customers by email address, and when more than one matches it gives preference to the one marked Y. Changing this static to N, or removing the mapping so that Counterpoint applies its own default of N, therefore also changes which existing customer a later transfer resolves to. Subscribers should leave it as it is unless they have a specific reason to do otherwise.

Source:

Destination: CUST_NO

This is a required field — NCR Counterpoint rejects the customer without it. The customer number, which is how Counterpoint identifies the customer. Counterpoint stores this as text of up to 15 characters.

The formula decides between reusing an existing Counterpoint customer and creating a new one. It searches Counterpoint for a customer whose email address matches the incoming customer's email address. If exactly one matches, that customer's number is used and the transfer updates that customer rather than creating a second one. If more than one matches, the customer marked as an e-commerce customer is preferred, and failing that the first match is used. If nothing matches, the formula supplies the value that tells Counterpoint to assign a new customer number itself. This is what keeps a returning shopper from accumulating duplicate Counterpoint records.

The value written here is Counterpoint's own customer identifier, and the transfer does not check it against the customers already in Counterpoint before writing. As shipped that is not a risk: the mapping either reuses a number it has just read back from Counterpoint, or hands the assignment to Counterpoint. It matters for subscribers who replace this mapping with one that supplies their own numbers. A number that already belongs to a different Counterpoint customer is accepted by the transfer and written onto that existing customer rather than being reported as a transfer error, and the result — one customer's details standing over another's — is noticed later, when that customer is used elsewhere in Counterpoint. Subscribers taking that route should confirm in a staging environment that the numbers they produce do not collide with customers already in Counterpoint.

Auto-Assign Customer Numbers MUST be enabled in NCR Counterpoint, for the workgroup the integration uses, before the first transfer. The formula relies on Counterpoint assigning the number for every customer that does not already exist, which is the normal case for a new install. Without that setting, Counterpoint has no number to assign and new customers do not transfer. Subscribers or their MiSP should confirm the setting at install time. Subscribers who instead want to supply their own customer numbers must replace this mapping with a formula that produces them, and must guarantee the numbers are unique — Counterpoint identifies customers by this value.

Because matching is done on the email address, a customer arriving from iPaaS.com without one cannot be matched to an existing Counterpoint customer and is always created as a new one. See EMAIL_ADRS_1 below.

Where the formula creates a new customer rather than reusing an existing one, Counterpoint does not start from a blank record. It copies the field values from the template customer assigned to the workgroup the transfer is running under, and then applies the values this collection maps on top. That matters because this collection does not map every field Counterpoint holds against a customer — a customer record carries far more definition than the integration supplies — so the template is what fills in everything the mappings leave untouched. Balances, last sale and payment figures, loyalty totals and the customer number itself are not copied; those belong to the new customer rather than the template.

Because of that, the workgroup must have a template customer defined. Where it does not, a new customer cannot be built and the transfer is refused with the error Unable to load the specified template customer, returned as a Bad Request and surfaced at Dashboard / Integration Monitoring / Error Logs. This is a genuine transfer failure rather than a value quietly stored and left to surface later, and it affects only the creation of new customers — updates to a customer Counterpoint already holds do not go near the template. Where a custom field named WRKGRP_ID is present on the incoming customer, that field decides which workgroup — and therefore which template customer — is used. Subscribers or their MiSP should confirm a template customer is defined for the workgroup these transfers run under before enabling this collection.

Source: Truncate(EmailAddress, 50) · Destination: EMAIL_ADRS_1

This is a recommended field. The customer's email address. Counterpoint stores this as text of up to 50 characters, and the formula trims the value to 50 so that a longer address is shortened to fit rather than arriving over-length.

Counterpoint accepts a customer with no email address, but this integration depends on it: the CUST_NO mapping above matches incoming customers against existing Counterpoint customers by this address, so a customer transferred without one is always created as a new Counterpoint record and can never be matched to an existing one. Subscribers should treat a populated email address as necessary for any install where duplicate customers matter, and should confirm iPaaS.com is supplying it before enabling this collection.

The trim deserves attention for the same reason. An email address longer than 50 characters is stored in its shortened form, and a shortened address will not match the full address on a later transfer. Subscribers whose customers may have long email addresses should be aware that matching is done on what Counterpoint stored.

Source: Truncate(FirstName,15) · Destination: FST_NAM

This is a recommended field. The customer's first name, held separately from the combined NAM value above. Counterpoint stores this as text of up to 15 characters, and the formula trims the value to 15 so that a longer first name is shortened to fit.

Counterpoint accepts a customer without a first name, but for a customer with no company the NAM mapping above builds the displayed name out of the first and last names — so a customer arriving with neither is created with an effectively blank name. Subscribers should treat this as recommended for any customer who is a person rather than a business.

Source: Truncate(LastName,25) · Destination: LST_NAM

This is a recommended field. The customer's last name, held separately from the combined NAM value above. Counterpoint stores this as text of up to 25 characters, and the formula trims the value to 25 so that a longer last name is shortened to fit. As with FST_NAM above, Counterpoint accepts a customer without one, but for a customer with no company the displayed name is built from the first and last names together — so subscribers should treat this as recommended for any customer who is a person rather than a business.

Parent: Add/Update NCR Counterpoint Customer FROM iPaaS.com.

Mapping Filter

Filter Description.

The filter decides which of a customer's iPaaS.com addresses become ship-to addresses in NCR Counterpoint. It excludes an address in two cases: when the address is flagged in iPaaS.com as the customer's primary billing address, and when the address has previously been transferred and is already linked to the customer's billing record in Counterpoint. Every other address transfers as a ship-to address. Without the filter, the customer's billing address — which the parent collection already writes onto the customer record — would be created a second time as a ship-to address, so subscribers should leave it in place.

Source:

Destination: SHIP_ADRS_ID

This field is required in practice. Counterpoint accepts the record without it and records (DEFAULT) instead, so the transfer succeeds either way — but every address arriving without one is then created under that same single identifier, and a customer would never hold more than one ship-to address. It should be mapped.

The identifier that distinguishes this address from the customer's other ship-to addresses. Counterpoint stores it as text of up to 10 characters. The formula checks whether this address has been sent to Counterpoint before. If it has not, the identifier is derived from the iPaaS.com address's own identifier so that a new address gets a new ship-to record. If it has, the formula supplies the identifier previously recorded for it — an identifier already held against that customer in Counterpoint, so the transfer updates that ship-to address rather than adding another.

The value is not checked against the ship-to addresses the customer already holds as part of the transfer, and nothing is reported when two of them resolve to the same identifier. Because Counterpoint accepts at most 10 characters here and shortens anything longer to fit, the identifiers this formula produces must be distinguishable from one another within their first 10 characters; two that are not collapse onto a single ship-to record, and the transfer still succeeds. That is not raised as a transfer error — it is noticed later, when an address expected in Counterpoint turns out not to be there, or a Counterpoint function reads an address that is not the one intended. Subscribers whose iPaaS.com address identifiers are long, or share a long common prefix, should confirm on a small number of records in a staging environment that each address lands as a separate ship-to record before enabling this collection for a full customer base. Subscribers should not replace this mapping with a fixed value — that would collapse every address onto a single ship-to record.

Source: (Coalesce(Company, "") == "" ? "P" : "B") · Destination: SHIP_NAM_TYP

This is a recommended field. Allowed values: B for a business and P for a person; Counterpoint accepts nothing else. Records which naming style the NAM value below uses, so that Counterpoint formats and searches the ship-to name correctly. An address with a company on it is marked as a business; an address with no company — whether the company is blank or absent altogether — is marked as a person.

Counterpoint supplies B of its own accord when nothing is mapped here, so an address still transfers if this mapping is removed, but every ship-to address would then be recorded as a business regardless of the name actually stored. Subscribers replacing this mapping should keep it derived from the same source as NAM below.

Source: Truncate(Region, 10) · Destination: STATE

This is an optional field. The state, province or region of the ship-to address. Counterpoint stores this as free text of up to 10 characters, and the formula trims the value to 10 so that longer region names are shortened to fit. Because 10 characters is short, subscribers whose iPaaS.com records hold full region names rather than abbreviations should expect the stored value to be the shortened form, and should replace this mapping with a formula that converts full names to the abbreviations their Counterpoint installation expects. Shipping decisions are commonly made on this value, so it is worth confirming it arrives in the form the installation expects before enabling this collection.

Source: Truncate(Address1,40) · Destination: ADRS_1

This is an optional field. The first line of the ship-to address. Counterpoint stores this as text of up to 40 characters, and the formula trims the value to 40 so that a longer address line is shortened to fit. Counterpoint accepts a ship-to address with no address lines at all, so subscribers should confirm iPaaS.com is supplying them before enabling this collection — an address that arrives without them is created rather than rejected, and is of no use for shipping.

Source: Truncate(Address2,40) · Destination: ADRS_2

This is an optional field. The second line of the ship-to address; addresses with only one line transfer with it empty. Counterpoint stores this as text of up to 40 characters, and the formula trims the value to 40 so that a longer address line is shortened to fit.

Source: Truncate(Address3,40) · Destination: ADRS_3

This is an optional field. The third line of the ship-to address; addresses with fewer lines transfer with it empty. Counterpoint stores this as text of up to 40 characters, and the formula trims the value to 40 so that a longer address line is shortened to fit.

Source: Truncate(PostalCode,15) · Destination: ZIP_COD

This is an optional field. The postal code of the ship-to address. Counterpoint stores this as free text of up to 15 characters, which accommodates the postal code formats in normal use, and the formula trims the value to 15 so that anything longer is shortened to fit. As with STATE above, shipping and tax decisions are commonly made on this value, so it is worth confirming it arrives populated before enabling this collection.

Source: Truncate(FirstName,15) · Destination: FST_NAM

This is a recommended field. The first name of the person at the ship-to address, held separately from the combined NAM value below. Counterpoint stores this as text of up to 15 characters, and the formula trims the value to 15 so that a longer first name is shortened to fit. Counterpoint accepts a ship-to address without one, but for an address with no company the NAM mapping below builds the displayed name out of the first and last names together, so subscribers should treat this as recommended for any address that goes to a person rather than a business.

Source: Truncate(LastName,25) · Destination: LST_NAM

This is a recommended field. The last name of the person at the ship-to address, held separately from the combined NAM value below. Counterpoint stores this as text of up to 25 characters, and the formula trims the value to 25 so that a longer last name is shortened to fit. As with FST_NAM above, Counterpoint accepts a ship-to address without one, but for an address with no company the displayed name is built from the first and last names together.

Source: Truncate(City,20) · Destination: CITY

This is an optional field. The city of the ship-to address. Counterpoint stores this as text of up to 20 characters — noticeably shorter than the address lines — and the formula trims the value to 20 so that longer city names are shortened to fit. Subscribers whose city names commonly exceed 20 characters should be aware that the stored value is the shortened form.

Source: Truncate(Country,20) · Destination: CNTRY

This is an optional field. The country of the ship-to address. Counterpoint stores this as free text of up to 20 characters rather than a fixed list of country codes, and the formula trims the value to 20 so that longer country names are shortened to fit. Whatever form iPaaS.com holds the country in is what Counterpoint receives, so subscribers who need a particular form — full names rather than two-letter codes, for example — should confirm that iPaaS.com supplies it consistently, or replace this mapping with a formula that converts it.

Source: Truncate((Company == "" ? (FirstName + " " + LastName) : Company),40) · Destination: NAM

This is a required field — NCR Counterpoint rejects the ship-to address without it. The name Counterpoint displays and ships to for this address. Counterpoint holds a single name per ship-to address rather than separate business and personal names, so the formula decides which to supply. When the address has a company, the company is used. When the address's company is blank, the first and last names are joined with a space. This mapping pairs with SHIP_NAM_TYP above, which records which of the two styles was used.

Counterpoint stores this as text of up to 40 characters, and the formula trims the result to 40 so that longer names are shortened to fit. Subscribers replacing this mapping should keep the trim.

The two mappings test the address's company differently, and subscribers should be aware of what that means in practice. SHIP_NAM_TYP treats an address whose company is absent altogether the same as one whose company is blank, and marks both as a person. This mapping treats only a blank company that way: an address whose company is absent rather than blank takes the company branch, and the address is left with no name — which Counterpoint rejects, so the address does not transfer. Subscribers whose iPaaS.com addresses may arrive with no company value at all should replace this mapping with a formula that falls back to the first and last names in that case as well, and should confirm the behavior in a staging environment before enabling this collection for a full customer base.

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.