Summary
This mapping collection brings companies from NCR Counterpoint into iPaaS.com, as part of the integration's customer-as-company feature. NCR Counterpoint has no company record of its own: a business that buys from you is an ordinary Counterpoint customer. Subscribers or their MiSP mark such customers with a field value of their choosing (see Customer-as-company Settings below), and a marked customer transfers to iPaaS.com as a company instead of as a customer. A company that iPaaS.com does not yet hold is created; one it already holds is updated. The collection carries the customer's name, email address, telephone number, customer number and category onto the company, and its four child collections carry the company's billing address, its ship-to addresses, and its links to its first and second contacts, who arrive as iPaaS.com customers with their roles in the company. The outcome is that a business customer created in Counterpoint reaches iPaaS.com as a company with its buyers, ready for business-to-business storefronts such as Adobe Commerce/Magento 2 B2B.
Customer-as-company is for new customers. Create a new Counterpoint customer for each company. Switching an existing customer to a company in place, by setting the marker on a customer that has already transferred to iPaaS.com, is not supported: its existing iPaaS.com customer record stops receiving its changes, and systems that record is linked to, such as a storefront, can refuse the new company's contacts. A marker that existing customers carry corrupts their records: if customers already in iPaaS.com carry it, for example with CUST_NAM_TYP (Name type) and B (Business), setting the customer-as-company settings switches every one of them to a company in place on its next change, and each must then be repaired by hand (see Customer-as-company Settings).
ID Format
Manual Sync id: the company's Counterpoint customer number, for example 1001. This collection reads inbound from Counterpoint, so the id entered on the Manual Sync page is the Counterpoint-side number, not an iPaaS.com value. A Manual Sync of this collection transfers any customer number it is given as a company; read Manual Sync under Mapping Collection Status before using it.
External ID saved after transfer: once a company has been transferred, iPaaS.com records its Counterpoint customer number as the external ID on a dedicated platform-managed external-ID record. That record, not any field on the company itself, is the match that routes later transfers of the same customer to the existing iPaaS.com company rather than adding a second one. The AccountNumber mapping also writes the customer number onto the company, so subscribers or their MiSP can see which Counterpoint customer it came from.
The contacts' external IDs: each contact is an iPaaS.com customer whose external ID is the company's customer number followed by :CONTCT_1 or :CONTCT_2; for customer number 1001, the contacts are 1001:CONTCT_1 and 1001:CONTCT_2.
The billing address's external ID: because the billing address is derived from the customer record rather than being a record of its own in Counterpoint, iPaaS.com identifies it by the company's Counterpoint customer number alone, for example 1001. That value routes a later transfer of the same company's billing address to the existing iPaaS.com address rather than adding a second one.
Each ship-to address's external ID: the company's Counterpoint customer number and the address's Counterpoint ship-to address id, joined by a pipe, for example 1001|(DEFAULT). As with the billing address, it routes a later transfer of the same address to the existing iPaaS.com address.
Deleted Record Support
This family does not carry deletions: each of its five collections adds or updates records, and none removes a company, a contact or a relationship from iPaaS.com. Clearing a contact in Counterpoint removes nothing; removing one is a manual procedure, described under Additional Notes. See NCR Counterpoint Known Limitations.
Mapping Collection Status
Status: Enabled. Add/Update NCR Counterpoint Company TO iPaaS.com has no mapping filter: changes reported by CPWebhooks, and scheduled polls, transfer a customer as a company only when it matches the customer-as-company settings, and none does while either setting is blank. A Manual Sync of this collection is the exception (see Manual Sync below). The four child collections are enabled as well; each one's mapping filter is described with it under Mappings.
Trigger Events: company transfers are started by the Customer trigger subscriptions, customer/created and customer/updated, which subscribers or their MiSP enable in the subscription configuration's Inbound Data Flows section; there is no separate company trigger to enable. When CPWebhooks reports a change to a customer that matches the customer-as-company settings, the integration transfers that customer through this collection instead of through Add/Update NCR Counterpoint Customer TO iPaaS.com. CPWebhooks must be installed and configured on the Counterpoint side first, as described in NCR Counterpoint Installation Instructions. No company transfers occur through CPWebhooks until it is configured, the Customer subscriptions are enabled in Inbound Data Flows, and both customer-as-company settings are set.
Which changes are reported: as installed, the Customer subscriptions carry a Counterpoint-side filter that reports a change to a customer only while it is an e-commerce customer with an Email 1, so a company's changes reach iPaaS.com through CPWebhooks only while both are true. That filter can be changed only on the Counterpoint side, which is a task for subscribers' MiSP. Whether a transferred company is added or updated is decided by whether it is already linked by an external ID.
Scheduled polling: where Counterpoint customers are polled on a schedule instead of, or as well as, through CPWebhooks, the Customer poll skips customers that match the customer-as-company settings, and this collection's poll picks them up. Subscribers or their MiSP give this collection the same schedule, with the same filter, as the Customer poll. Its poll transfers every customer its filter selects that carries the marker, whether or not it is an e-commerce customer yet, so give it a filter that selects e-commerce customers only. A company transferred by a scheduled poll arrives with its billing address but without its ship-to addresses, which are loaded only for changes reported by CPWebhooks and for a Manual Sync.
Manual Sync: available on this collection, as it is on every mapping collection; enter the company's Counterpoint customer number. A Manual Sync of this collection transfers any customer number it is given as a company, whether or not that customer carries the marker, and even while the customer-as-company settings are blank. Use it only for customers that carry the marker, and only while both customer-as-company settings are set: an unmarked customer transferred this way gets a company in iPaaS.com, and its later changes then reach neither that company nor its iPaaS.com customer record, because the Customer collection's mapping filter holds back a customer number that has a company; while the settings are blank, the customer's later changes also transfer it as an ordinary customer. Do not enter a company's customer number in a Manual Sync of Add/Update NCR Counterpoint Customer TO iPaaS.com. The four child collections have no Manual Sync entry point of their own: they transfer as part of the company, so re-sync the company instead.
Duplicate or Conflicting Mappings
Add/Update NCR Counterpoint Customer TO iPaaS.com: reads the same Counterpoint customers. For a change reported by CPWebhooks, the integration runs one of the two collections for each customer: Add/Update NCR Counterpoint Company TO iPaaS.com when the customer matches the customer-as-company settings, and the Customer collection otherwise. Scheduled polls are separate: the Customer collection's poll skips customers that match the settings, and they transfer only through this collection's own poll (see Scheduled polling above). The Customer collection also transfers the company's contacts (see Integration Flow), and its mapping filter stops a customer whose customer number already has an iPaaS.com company from also being sent as a customer.
Important: keep the customer-as-company part of the Customer collection's mapping filter in place, and choose a marker that no existing customer carries (see Customer-as-company Settings).
Supported Child Collections
Add/Update NCR Counterpoint Company Billing Address TO iPaaS.com: carries the address held on the Counterpoint customer record as the company's primary billing address.
Add/Update NCR Counterpoint Company Ship-To Address TO iPaaS.com: carries every ship-to address the customer has in Counterpoint, not only the default one (a scheduled poll excepted; see Scheduled polling above), and marks the default one as the company's primary shipping address. The company's contacts do not receive the ship-to addresses, and Adobe Commerce/Magento 2 receives only the company's billing address.
Add/Update NCR Counterpoint Company Contact 1 Relationship TO iPaaS.com: links the company to its first contact, marks that contact as the company's primary contact, and sets its role.
Add/Update NCR Counterpoint Company Contact 2 Relationship TO iPaaS.com: links the company to its second contact, when there is one, and sets that contact's role.
All four transfer as part of the company; none has a Manual Sync entry point of its own.
Customer-as-company Settings
Two settings on the NCR Counterpoint subscription decide which Counterpoint customers transfer as companies. Both are also described in NCR Counterpoint Connections and Settings.
Customer-as-company Field: the name of a Counterpoint customer field, or of a customer custom field, that marks a company. For a Counterpoint field, spell the name exactly as Counterpoint does, including capitalization. For example, USER_B2B_COMPANY, a new customer custom field, or PROF_ALPHA_5, a customer profile field used for nothing else.
Customer-as-company Field Value: the value that field holds on a company, for example Y or B2B. The match ignores capitalization and leading or trailing spaces.
While either setting is blank, changes reported by CPWebhooks and scheduled polls transfer no customer as a company, and every customer keeps transferring as a customer. A field name that is neither a Counterpoint customer field nor a custom field on the customer treats that customer as an ordinary customer, and records only a warning in the transfer's activity log. Keep in mind:
Use a dedicated marker that no existing customer carries: for example, a new custom field.
A marker that existing customers carry corrupts their records: with CUST_NAM_TYP (Name type) and B (Business), or any other field and value that customers already in iPaaS.com hold, setting both settings switches every one of those customers to a company in place on its next change. iPaaS.com gains a company record and new contact records beside each customer's existing record, which then stops receiving the customer's changes, and Adobe Commerce/Magento 2 creates an account for each contact that has none and, where the customer already has an account there, refuses Contact 1, whose email address belongs to that account, and the company. The integration has no safeguard against this: it does not check whether a marked customer is already in iPaaS.com, so it neither converts that customer's records nor keeps the customer transferring as a customer. Clearing the marker or the settings afterwards stops further switches but removes nothing, and each customer must be repaired by hand, as described in NCR Counterpoint Customer-as-Company Implementation Guide. Before setting both settings, check that no existing customer carries the marker.
A custom field used as the marker must be known to CPHive: add it to Counterpoint, then regenerate CPHive's data dictionary cache, as described under Generate the data dictionary cache in NCR Counterpoint Installation Instructions. Until then, the integration cannot read it, and no customer transfers as a company.
System Caveats
NCR Counterpoint Caveats
Mark a new company before it is first saved as an e-commerce customer: the first change CPWebhooks reports for a customer decides whether it first reaches iPaaS.com as a customer or as a company. Create the customer with its marker already set, and flag it as an e-commerce customer, with its Email 1, last. A new customer flagged as an e-commerce customer before its marker transfers as an ordinary customer, and setting the marker afterwards switches it to a company in place. If its Email 1 also belongs to a customer already in iPaaS.com, it is linked to that customer's iPaaS.com record instead of getting its own, and its data overwrites that record.
Contacts come from the Contact 1 and Contact 2 fields: keep each contact's own full name in them, and give Contact 2 its own Email 2. A contact with no name is not transferred. Where the customer form also shows the contacts in custom fields, those must hold the same names as Contact 1 and Contact 2: the integration reads the names from the standard fields and each contact's role from its custom type field.
The contact type fields are optional custom fields: USER_CONTCT_1_TYP and USER_CONTCT_2_TYP exist only where the subscriber's Counterpoint customer form has them. Without them, Contact 1 is the Super User, provided it has a name and is transferred, and Contact 2 is a User. The integration sees a custom field added later only once CPHive's data dictionary cache includes it; until then, the type fields read as unset.
The customer record's own name and Phone 1 go onto the billing addresses: the recipient first and last names on the company's and its contacts' billing addresses are read from the customer record, not from a contact, and Phone 1 is sent as the telephone number on those addresses. Fill in First name, Last name and Phone 1 on each company's customer record in Counterpoint; where the names are blank, the address transfers without a recipient name.
The company's category is sent twice: as the company's category assignment, and as the Counterpoint category code in Department.
iPaaS.com Caveats
The name and department together must be unique: iPaaS.com refuses a new company whose name and department match an existing company's. Because Department carries the Counterpoint category code, two companies with the same name and the same category collide; give each company a distinct name, and keep Department mapped from the category code: Adobe Commerce/Magento 2 takes the company's customer group from the category it names.
Categories must be transferred before companies to arrive assigned: a company's category is resolved by looking up a category already transferred into iPaaS.com. Subscribers or their MiSP should run Add/Update NCR Counterpoint Customer Category TO iPaaS.com before this collection; a category with no match is skipped rather than failing the transfer.
Every company needs its own Email 1: a contact's address is Email 1 or Email 2 with its prefix, so two companies with the same Email 1 give their Contact 1 the same iPaaS.com address, and the second company's contact is matched to the first company's or, where that link cannot be made, fails with CRPT-BIZL-1002, which stops the second company (see Integration Flow). Give every Contact 2 its own Email 2 as well: Adobe Commerce/Magento 2 removes the prefix and, when Contact 2 has Contact 1's address, refuses whichever of the two it writes second, which stops the whole company there.
The contacts must pass the Customer collection's mapping filter: each relationship points to its contact's iPaaS.com customer record, which the company's transfer creates beforehand through Add/Update NCR Counterpoint Customer TO iPaaS.com. A contact that does not pass that collection's mapping filter has no record to point to. As installed, that filter admits only e-commerce customers, so flag each company as one.
A country is supplied when Counterpoint has none: where the customer record or a ship-to record carries no country, United States is sent instead. The fallback applies per address, so addresses that do have a country recorded keep their own value. Subscribers or their MiSP whose companies are predominantly outside the United States should replace the fallback with the country appropriate to their business, because it is applied silently.
Integration Flow
The company's contacts are transferred first, as iPaaS.com customers. Before the company itself is written, its contacts are transferred to iPaaS.com as customers, automatically, through Add/Update NCR Counterpoint Customer TO iPaaS.com: Contact 1 first, then Contact 2. A contact is transferred only when its name (Contact 1 or Contact 2) is filled in Counterpoint, and each contact:
is identified by the company's customer number followed by :CONTCT_1 or :CONTCT_2, for example 1001:CONTCT_1;
is named from its own contact name: the last word becomes the last name and the rest the first name, and a one-word name is used as both;
gets Email 1 (Contact 1) or Email 2 (Contact 2) with a CONTCT_1: or CONTCT_2: prefix; a Contact 2 with no Email 2 gets Email 1 instead;
gets the company's billing address, and no ship-to addresses.
A contact that cannot be transferred stops the company transfer, with the contact's own error or with CRPT-BIZL-1005 in Dashboard / Integration Monitoring / Error Logs, and the company is not written. A contact that the Customer collection's mapping filter holds back is different: it is skipped without an error, and so is its relationship, so the company is written without it, unless the contact is designated the Super User, which stops the company with CRPT-BIZL-1008. As installed, that filter admits only e-commerce customers, so flag each company as one. Adobe Commerce/Magento 2 refuses a company that arrives with no Super User.
The CONTCT_1: and CONTCT_2: prefix keeps a contact's address apart from the ordinary customers', so a contact is never linked to an ordinary customer with the same address. It does not separate companies: two companies with the same Email 1, or with none, give their contacts the same address, and the second company's contact is matched to the first company's contact record instead of getting its own or, where that link cannot be made, fails with CRPT-BIZL-1002, and the second company is not written. The prefix is kept in iPaaS.com by design. Adobe Commerce/Magento 2 version 1.4.10 or later removes it when it writes the contact; earlier versions send the prefixed address, which Adobe Commerce rejects as invalid.
The company is sent to iPaaS.com, where subsequent transfers are routed by the external ID recorded on transfer.
Child records transfer as part of the same transfer: the collections listed under Supported Child Collections above. A contact relationship is skipped when its contact has no iPaaS.com customer record, and the relationship collections' mapping filters stop the company's transfer with a coded error when the contacts' Super User designations are inconsistent or incomplete (see each relationship collection under Mappings).
Mappings
Add/Update NCR Counterpoint Company TO iPaaS.com
Mapping Type | Source Field (NCR Counterpoint) | Destination Field (iPaaS.com) | Description |
Field |
| Name | Required. iPaaS.com rejects a company without one. |
Field |
| AccountNumber | Recommended. Shows which Counterpoint customer the company came from. |
Field |
| EmailAddress | Recommended. Also Contact 1's email address. |
Field |
| PhoneNumber | Recommended. Also the telephone on the company's and its contacts' billing addresses. |
Dynamic Formula |
| Categories | Optional. Downstream platforms can require it. |
Field |
| Department | Optional. Part of the name and department uniqueness rule. |
Name — Field
Source: NAM · Destination: Name
This is a required field: iPaaS.com rejects a company without a name. The customer's name as recorded in NCR Counterpoint, which Counterpoint always requires, so a value of up to 40 characters always arrives. iPaaS.com also requires a new company's name and department together to be unique; see Department below.
AccountNumber — Field
Source: CUST_NO · Destination: AccountNumber
This is a recommended field. The company's customer number as assigned in NCR Counterpoint, which Counterpoint stores as text of up to 15 characters and always populates. It lets subscribers or their MiSP see which Counterpoint customer an iPaaS.com company came from. The match that routes later transfers to the same company is the external ID iPaaS.com saves after the first transfer, not this field.
EmailAddress — Field
Source: EMAIL_ADRS_1 · Destination: EmailAddress
This is a recommended field. The customer's Email 1 from NCR Counterpoint, which Counterpoint stores as text of up to 50 characters. It is also Contact 1's email address: the contact's iPaaS.com record carries it with a CONTCT_1: prefix. Counterpoint reports a customer's changes only while it is an e-commerce customer with an Email 1, so a company needs one for its changes to reach iPaaS.com through CPWebhooks.
Adobe Commerce/Magento 2 requires a company email address and finds an existing company by it, so keep Email 1 unchanged once a company has reached it: changing it stops the company's transfers there until it is put back.
PhoneNumber — Field
Source: PHONE_1 · Destination: PhoneNumber
This is a recommended field. The customer's Phone 1 from NCR Counterpoint, which Counterpoint stores as text of up to 25 characters and permits to be empty. The same number is sent as the telephone on the company's billing address and on each contact's billing address. Adobe Commerce/Magento 2 requires a telephone number on the company's billing address and, by default, on every customer address, including the contacts' billing addresses, so a company with no Phone 1 can be refused there.
Categories — Dynamic Formula
Source: return await ConvertCustomerCategoriesToiPaaSIdListAsync(CATEG_COD); · Destination: Categories
This is an optional field for iPaaS.com. It assigns the company to the iPaaS.com customer category that its NCR Counterpoint category was transferred as, looked up by the Counterpoint category code. The category must already have been transferred by Add/Update NCR Counterpoint Customer Category TO iPaaS.com; a code with no match is skipped, and the company transfers without that category. Downstream platforms can require a category: Adobe Commerce/Magento 2 builds the company's customer group from it and refuses a company with none.
When the category changes in Counterpoint, iPaaS.com adds the new category and keeps the old one, and a company's last category cannot be removed. The company's Adobe Commerce/Magento 2 customer group follows its current category: the Adobe Commerce/Magento 2 company collection takes the category named by the company's Department, which this collection sets to the current category code on every transfer. An Adobe Commerce/Magento 2 subscription still on the earlier mapping, which takes the first category, keeps the company in its first group until that mapping is updated.
Department — Field
Source: CATEG_COD · Destination: Department
This is an optional field. It holds the company's NCR Counterpoint category code as text. iPaaS.com requires a new company's name and department together to be unique, so two companies with the same name and the same category code collide, and the second is refused. Subscribers or their MiSP should give each company a distinct name. Adobe Commerce/Magento 2 also takes the company's customer group from the category Department names, so a Department mapped from another value leaves a company whose category changed in the group of its first category.
Add/Update NCR Counterpoint Company Billing Address TO iPaaS.com
Parent: Add/Update NCR Counterpoint Company TO iPaaS.com.
Mapping Filter
SourceTypeName == "ParentOnly"
Filter Description.
The filter admits only the address derived from the customer record itself, the billing address, and excludes the customer's ship-to records, which are handled by Add/Update NCR Counterpoint Company Ship-To Address TO iPaaS.com. Every mapping in this collection reads from the parent customer accordingly. Subscribers should leave this filter in place: without it, this collection and the ship-to collection would both process the same records.
Mapping Type | Source Field (NCR Counterpoint) | Destination Field (iPaaS.com) | Description |
Dynamic Formula |
| FirstName | Recommended. The recipient's first name. |
Dynamic Formula |
| LastName | Recommended. The recipient's last name. |
Dynamic Formula |
| Address1 | Recommended. Makes the address usable for billing. |
Dynamic Formula |
| Address2 | Optional. Suite, unit or similar detail. |
Dynamic Formula |
| Address3 | Optional. A third address line. |
Dynamic Formula |
| City | Recommended. Needed for a deliverable address. |
Dynamic Formula |
| Region | Recommended. Must be valid for the country downstream. |
Dynamic Formula |
| Country | Recommended. Falls back to United States. |
Dynamic Formula |
| PostalCode | Recommended. Needed for tax and shipping. |
Dynamic Formula |
| PhoneNumber | Recommended. The company's Phone 1. |
Static |
| IsPrimaryBilling | Recommended. Marks the company's primary billing address. |
FirstName — Dynamic Formula
Source: Parent.FST_NAM · Destination: FirstName
This is a recommended field. The first name from the company's customer record in NCR Counterpoint, used as the recipient's first name because Counterpoint does not hold a separate name against the billing address. Counterpoint stores it as text of up to 15 characters and permits it to be empty, in which case the address transfers without a first name. Adobe Commerce/Magento 2 requires a recipient name on the company's and its contacts' billing addresses, so fill in the first name on each company's customer record.
LastName — Dynamic Formula
Source: Parent.LST_NAM · Destination: LastName
This is a recommended field. The last name from the company's customer record in NCR Counterpoint, used as the recipient's last name for the same reason as FirstName above. Counterpoint stores it as text of up to 25 characters and permits it to be empty.
Address1 — Dynamic Formula
Source: Parent.ADRS_1 · Destination: Address1
This is a recommended field. iPaaS.com accepts the address without it, but the first address line is what makes the address usable for billing and correspondence, and storefronts such as Adobe Commerce/Magento 2 require it. The first line of the billing address held on the company's customer record in NCR Counterpoint, which Counterpoint stores as text of up to 40 characters.
Address2 — Dynamic Formula
Source: Parent.ADRS_2 · Destination: Address2
This is an optional field. The second line of the billing address, used in NCR Counterpoint for suite, unit, or similar detail. Counterpoint stores it as text of up to 40 characters and permits it to be empty, which is the common case.
Address3 — Dynamic Formula
Source: Parent.ADRS_3 · Destination: Address3
This is an optional field. The third line of the billing address. Counterpoint stores it as text of up to 40 characters and permits it to be empty, which is the common case.
City — Dynamic Formula
Source: Parent.CITY · Destination: City
This is a recommended field. iPaaS.com accepts the address without it, but a billing address without a city is not deliverable, and storefronts such as Adobe Commerce/Magento 2 require it. The city from the billing address on the company's customer record, which Counterpoint stores as text of up to 20 characters.
Region — Dynamic Formula
Source: Parent.STATE · Destination: Region
This is a recommended field. The state or province from the billing address on the company's customer record, which Counterpoint stores as text of up to 10 characters without enforcing a fixed list of codes. Storefronts such as Adobe Commerce/Magento 2 need a state or region that is valid for the address's country, so use the form the storefront recognizes.
Country — Dynamic Formula
Source: Coalesce(Parent.CNTRY,"United States") · Destination: Country
This is a recommended field. iPaaS.com accepts the address without a country, but storefronts and shipping systems that read company data from iPaaS.com generally require one, which is why this mapping supplies a fallback. The country from the billing address on the company's customer record, which Counterpoint stores as text of up to 20 characters; when it is empty, the formula produces United States instead. A company whose customer record does have a country keeps its own value.
Subscribers or their MiSP whose companies are predominantly outside the United States should replace the fallback with the country appropriate to their business, because the fallback is applied silently.
PostalCode — Dynamic Formula
Source: Parent.ZIP_COD · Destination: PostalCode
This is a recommended field. The postal or ZIP code from the billing address on the company's customer record, generally needed for tax and shipping downstream, and required by storefronts such as Adobe Commerce/Magento 2. Counterpoint stores it as text of up to 15 characters and does not enforce a format on it.
PhoneNumber — Dynamic Formula
Source: Parent.PHONE_1 · Destination: PhoneNumber
This is a recommended field. The company's Phone 1 from NCR Counterpoint, sent as the telephone number on the billing address. Counterpoint stores it as text of up to 25 characters and permits it to be empty. Adobe Commerce/Magento 2 requires a telephone number on the company's billing address and, by default, on every customer address, so a company with no Phone 1 can be refused there. The company's contacts receive the same number on their billing addresses.
IsPrimaryBilling — Static
Source: true · Destination: IsPrimaryBilling
This is a recommended field. Marks the address as the company's primary billing address in iPaaS.com, which is the address Adobe Commerce/Magento 2 takes the company's own address from. The value is fixed rather than read from NCR Counterpoint because the collection's filter restricts it to the one billing address held on the customer record. Subscribers or their MiSP should leave it set; clearing it leaves the company with no address marked for billing, and Adobe Commerce/Magento 2 without the company's address.
Add/Update NCR Counterpoint Company Ship-To Address TO iPaaS.com
Parent: Add/Update NCR Counterpoint Company TO iPaaS.com.
Mapping Filter
SourceTypeName != "ParentOnly"
Filter Description.
The filter excludes the address derived from the customer record, which is the billing address handled by Add/Update NCR Counterpoint Company Billing Address TO iPaaS.com, and admits every genuine ship-to record. Unlike Add/Update NCR Counterpoint Customer Ship-To Address TO iPaaS.com, which transfers only a customer's default ship-to address, this filter has no condition on the ship-to address id, so a company arrives with all of its ship-to addresses (a scheduled poll excepted; see Scheduled polling above). Subscribers should leave this filter in place: without it, this collection and the billing address collection would both process the billing address.
Mapping Type | Source Field (NCR Counterpoint) | Destination Field (iPaaS.com) | Description |
Field |
| FirstName | Optional. The ship-to contact's first name. |
Field |
| LastName | Optional. The ship-to contact's last name. |
Field |
| Address1 | Recommended. Makes the address usable for shipping. |
Field |
| Address2 | Optional. Suite, unit or similar detail. |
Field |
| Address3 | Optional. A third address line. |
Field |
| City | Recommended. Needed for a deliverable address. |
Field |
| Region | Recommended. Needed for tax and shipping. |
Field |
| PostalCode | Recommended. Needed for shipping and rate calculation. |
Dynamic Formula |
| Company | Optional. Sent for business ship-to addresses only. |
Dynamic Formula |
| IsPrimaryShipping | Optional. Marks the default ship-to address as primary. |
Dynamic Formula |
| Country | Recommended. Falls back to United States. |
FirstName — Field
Source: FST_NAM · Destination: FirstName
This is an optional field. The first name of the contact recorded against this ship-to address in NCR Counterpoint. A ship-to record carries its own name, so this is not the company's name unless someone entered the same value. Counterpoint stores it as text of up to 15 characters and permits it to be empty.
LastName — Field
Source: LST_NAM · Destination: LastName
This is an optional field. The last name of the contact recorded against this ship-to address in NCR Counterpoint. Counterpoint stores it as text of up to 25 characters and permits it to be empty.
Address1 — Field
Source: ADRS_1 · Destination: Address1
This is a recommended field. iPaaS.com accepts the address without it, but the first address line is what makes the address usable for shipping. The first line of the ship-to address in NCR Counterpoint, which Counterpoint stores as text of up to 40 characters.
Address2 — Field
Source: ADRS_2 · Destination: Address2
This is an optional field. The second line of the ship-to address, used in NCR Counterpoint for suite, unit, or similar detail. Counterpoint stores it as text of up to 40 characters and permits it to be empty, which is the common case.
Address3 — Field
Source: ADRS_3 · Destination: Address3
This is an optional field. The third line of the ship-to address. Counterpoint stores it as text of up to 40 characters and permits it to be empty, which is the common case.
City — Field
Source: CITY · Destination: City
This is a recommended field. iPaaS.com accepts the address without it, but a ship-to address without a city is not deliverable. The city from the ship-to address in NCR Counterpoint, which Counterpoint stores as text of up to 20 characters.
Region — Field
Source: STATE · Destination: Region
This is a recommended field. The state or province from the ship-to address in NCR Counterpoint, generally needed for tax and shipping downstream. Counterpoint stores it as text of up to 10 characters and does not enforce a fixed list of codes, so it carries whatever form the subscriber's Counterpoint installation uses.
PostalCode — Field
Source: ZIP_COD · Destination: PostalCode
This is a recommended field. The postal or ZIP code from the ship-to address in NCR Counterpoint, generally needed for shipping and rate calculation downstream. Counterpoint stores it as text of up to 15 characters and does not enforce a format on it.
Company — Dynamic Formula
Source: (SHIP_NAM_TYP == "B" ? NAM : null) · Destination: Company
This is an optional field. NCR Counterpoint records a ship-to address under a single name field together with a name-type flag that marks it as either a business or a person. When the flag is B, the address belongs to a business and the Counterpoint name is sent as the company name; for any other value no company name is sent, because for a person the name is already carried by the FirstName and LastName mappings. Business ship-to addresses arrive with a company name of up to 40 characters.
IsPrimaryShipping — Dynamic Formula
Source: (SHIP_ADRS_ID == "(DEFAULT)" ? true : false) · Destination: IsPrimaryShipping
This is an optional field. Marks the company's primary shipping address in iPaaS.com. Because this collection's filter admits every ship-to address, the formula sets the flag only on the address whose Counterpoint ship-to address id is (DEFAULT), which is the id Counterpoint assigns to a customer's default ship-to address, and clears it on the others. Replacing it with a fixed value would mark every address as primary.
Country — Dynamic Formula
Source: Coalesce(CNTRY,"United States") · Destination: Country
This is a recommended field. iPaaS.com accepts the address without a country, but storefronts and shipping systems that read company data from iPaaS.com generally require one, which is why this mapping supplies a fallback. The country from the ship-to address in NCR Counterpoint, which Counterpoint stores as text of up to 20 characters; when it is empty, the formula produces United States instead. The fallback applies per address, so addresses that do have a country recorded keep their own value.
Subscribers or their MiSP whose companies are predominantly outside the United States should replace the fallback with the country appropriate to their business, because the fallback is applied silently.
Add/Update NCR Counterpoint Company Contact 1 Relationship TO iPaaS.com
Parent: Add/Update NCR Counterpoint Company TO iPaaS.com.
Mapping Filter
var t1 = GetCustomField_CPHive(Parent, "USER_CONTCT_1_TYP");
var c1 = t1 == null ? "" : t1.ToString().Trim().ToUpper().Replace(" ", "");
var t2 = GetCustomField_CPHive(Parent, "USER_CONTCT_2_TYP");
var c2 = t2 == null ? "" : t2.ToString().Trim().ToUpper().Replace(" ", "");
// "!" is Counterpoint's no-selection value: an unset Type is undesignated, and contact 1 is then the Super User by default.
if (c1 == "!") { c1 = ""; }
if (c2 == "!") { c2 = ""; }
var su1 = c1 == "S" || c1 == "SUPERUSER";
var su2 = c2 == "S" || c2 == "SUPERUSER";
if (su1 && su2) { throw new Exception("CRPT-VALD-1012 - Counterpoint customer " + Parent.CUST_NO + " has both Contact 1 and Contact 2 designated Super User. Designate exactly one contact as Super User." + " - https://support.ipaas.com/en/articles/16003194-ncr-counterpoint-error-messages"); }
if (c1 != "" && !su1 && !su2) { throw new Exception("CRPT-VALD-1013 - Counterpoint customer " + Parent.CUST_NO + " has no contact designated Super User. Designate Contact 1 or Contact 2 as Super User." + " - https://support.ipaas.com/en/articles/16003194-ncr-counterpoint-error-messages"); }
var su1Default = c1 == "" && !su2 && !string.IsNullOrWhiteSpace(Convert.ToString(Parent.CONTCT_1));
if ((su1 || su1Default) && string.IsNullOrEmpty(Parent.EMAIL_ADRS_1)) { throw new Exception("CRPT-VALD-1014 - Contact 1 of Counterpoint customer " + Parent.CUST_NO + " is the Super User, by its type or by default, but the customer has no Email 1, so the Super User would receive no email address. Enter Contact 1's email address in Email 1." + " - https://support.ipaas.com/en/articles/16003194-ncr-counterpoint-error-messages"); }
var contactId = await GetSpaceportIdAsync(Parent.CUST_NO + ":CONTCT_1", "Customer", SpaceportSystemId);
if (contactId == null) { if (su1) { throw new Exception("CRPT-BIZL-1008 - Contact 1 of Counterpoint customer " + Parent.CUST_NO + " is designated Super User but was not sent to iPaaS.com as a customer. Check that Contact 1 has a name in Counterpoint and that the customer passes the Customer TO iPaaS.com filter." + " - https://support.ipaas.com/en/articles/16003194-ncr-counterpoint-error-messages"); } return false; }
return true;
Filter Description.
The filter reads each contact's type from the Counterpoint custom fields USER_CONTCT_1_TYP and USER_CONTCT_2_TYP, ignoring capitalization and spaces. Counterpoint's no-selection value, !, counts as unset, and S or SUPERUSER designates a contact as the Super User. The filter then:
stops the company's transfer with CRPT-VALD-1012 when both contacts are designated Super User;
stops it with CRPT-VALD-1013 when Contact 1 has a type other than Super User and Contact 2 is not designated Super User, so the company would have none;
stops it with CRPT-VALD-1014 when Contact 1 is the Super User, designated or by default, but the customer has no Email 1;
skips the relationship when Contact 1 has no iPaaS.com customer record, for example because Contact 1 is empty, or stops the company's transfer with CRPT-BIZL-1008 when that contact is designated Super User;
otherwise lets the relationship transfer.
Each error message names the Counterpoint customer and what to correct there, and appears in Dashboard / Integration Monitoring / Error Logs. Subscribers should leave this filter in place.
Mapping Type | Source Field (NCR Counterpoint) | Destination Field (iPaaS.com) | Description |
Dynamic Formula |
| RelatedToId | Required. Points the relationship to Contact 1's customer record. |
Dynamic Formula | Formula reading USER_CONTCT_1_TYP and USER_CONTCT_2_TYP, shown in full below | Type | Recommended. Contact 1's role in the company. |
Static |
| IsPrimary | Optional. Contact 1 is always the primary contact. |
RelatedToId — Dynamic Formula
Source: await GetSpaceportIdAsync(Parent.CUST_NO + ":CONTCT_1", "Customer", SpaceportSystemId) · Destination: RelatedToId
This is a required field: iPaaS.com rejects a relationship that does not point to a customer. The formula finds Contact 1's iPaaS.com customer record by its external ID, the company's Counterpoint customer number followed by :CONTCT_1. The company's transfer creates that record before the relationship, through Add/Update NCR Counterpoint Customer TO iPaaS.com; when there is no such record, the collection's mapping filter skips the relationship, or stops the company's transfer when Contact 1 is designated Super User.
Type — Dynamic Formula
Source:
// Adobe Commerce/Magento 2 pre-creates only relationship types containing "user" before assigning them to the company.
// An unset Type ("!" is Counterpoint's no-selection value) is undesignated: contact 1 is then the Super User unless contact 2 is designated Super User.
var t1 = GetCustomField_CPHive(Parent, "USER_CONTCT_1_TYP");
var c1 = t1 == null ? "" : t1.ToString().Trim().ToUpper().Replace(" ", "");
if (c1 == "!") { c1 = ""; }
if (c1 == "S" || c1 == "SUPERUSER") { return "Super User"; }
if (c1 == "A" || c1 == "ADMIN") { return "Admin User"; }
if (c1 != "") { return "User"; }
var t2 = GetCustomField_CPHive(Parent, "USER_CONTCT_2_TYP");
var c2 = t2 == null ? "" : t2.ToString().Trim().ToUpper().Replace(" ", "");
return (c2 == "S" || c2 == "SUPERUSER") ? "User" : "Super User";
Destination: Type
This is a recommended field. Downstream storefronts decide each contact's role from it: Adobe Commerce/Magento 2 makes the Super User the company's administrator, and needs exactly one per company. The formula sets Contact 1's role from the NCR Counterpoint custom field USER_CONTCT_1_TYP, ignoring capitalization and spaces:
S or SUPERUSER: Super User, the company's administrator.
A or ADMIN: Admin User.
Any other value: User.
Unset (empty, or !, Counterpoint's no-selection value): Super User, unless Contact 2 is designated Super User, in which case User.
So a company whose contacts carry no types has Contact 1 as its Super User, provided Contact 1 has a name and is transferred. A company whose Contact 1 is empty, or held back by the Customer collection's mapping filter, has no Super User unless Contact 2 is designated; the integration records no error, but Adobe Commerce/Magento 2 refuses the company (MAGE-BIZL-1022). Always fill in Contact 1.
Every type contains the word User because Adobe Commerce/Magento 2 creates a contact's account ahead of the company only for relationships whose type contains that word, then assigns every related contact to the company; subscribers or their MiSP who change these values should keep that word. Adobe Commerce/Magento 2 assigns an Admin User to the company as an ordinary company user; only the Super User becomes the company's administrator there.
IsPrimary — Static
Source: true · Destination: IsPrimary
This is an optional field. Marks Contact 1's relationship as the company's primary contact. The value is fixed: Contact 1 is always the primary contact, and Contact 2 never is.
Add/Update NCR Counterpoint Company Contact 2 Relationship TO iPaaS.com
Parent: Add/Update NCR Counterpoint Company TO iPaaS.com.
Mapping Filter
var t1 = GetCustomField_CPHive(Parent, "USER_CONTCT_1_TYP");
var c1 = t1 == null ? "" : t1.ToString().Trim().ToUpper().Replace(" ", "");
var su1 = c1 == "S" || c1 == "SUPERUSER";
var t2 = GetCustomField_CPHive(Parent, "USER_CONTCT_2_TYP");
var c2 = t2 == null ? "" : t2.ToString().Trim().ToUpper().Replace(" ", "");
var su2 = c2 == "S" || c2 == "SUPERUSER";
if (su2 && string.IsNullOrEmpty(Parent.EMAIL_ADRS_2)) { throw new Exception("CRPT-VALD-1014 - Contact 2 of Counterpoint customer " + Parent.CUST_NO + " is designated Super User but the customer has no Email 2, so the Super User would receive Contact 1's email address. Enter Contact 2's email address in Email 2." + " - https://support.ipaas.com/en/articles/16003194-ncr-counterpoint-error-messages"); }
var contactId = await GetSpaceportIdAsync(Parent.CUST_NO + ":CONTCT_2", "Customer", SpaceportSystemId);
if (contactId == null) { if (su2) { throw new Exception("CRPT-BIZL-1008 - Contact 2 of Counterpoint customer " + Parent.CUST_NO + " is designated Super User but was not sent to iPaaS.com as a customer. Check that Contact 2 has a name in Counterpoint and that the customer passes the Customer TO iPaaS.com filter." + " - https://support.ipaas.com/en/articles/16003194-ncr-counterpoint-error-messages"); } return false; }
return true;
Filter Description.
The filter reads each contact's type from the Counterpoint custom fields USER_CONTCT_1_TYP and USER_CONTCT_2_TYP, ignoring capitalization and spaces; S or SUPERUSER designates a contact as the Super User. The filter then:
stops the company's transfer with CRPT-VALD-1014 when Contact 2 is designated Super User but the customer has no Email 2, because Contact 2 would otherwise carry Contact 1's email address;
skips the relationship when Contact 2 has no iPaaS.com customer record, for example because Contact 2 is empty, or stops the company's transfer with CRPT-BIZL-1008 when that contact is designated Super User;
otherwise lets the relationship transfer.
A company with both contacts designated Super User is stopped by Add/Update NCR Counterpoint Company Contact 1 Relationship TO iPaaS.com. Each error message names the Counterpoint customer and what to correct there, and appears in Dashboard / Integration Monitoring / Error Logs. Subscribers should leave this filter in place.
Mapping Type | Source Field (NCR Counterpoint) | Destination Field (iPaaS.com) | Description |
Dynamic Formula |
| RelatedToId | Required. Points the relationship to Contact 2's customer record. |
Dynamic Formula | Formula reading USER_CONTCT_2_TYP, shown in full below | Type | Recommended. Contact 2's role in the company. |
Static |
| IsPrimary | Optional. Contact 2 is never the primary contact. |
RelatedToId — Dynamic Formula
Source: await GetSpaceportIdAsync(Parent.CUST_NO + ":CONTCT_2", "Customer", SpaceportSystemId) · Destination: RelatedToId
This is a required field: iPaaS.com rejects a relationship that does not point to a customer. The formula finds Contact 2's iPaaS.com customer record by its external ID, the company's Counterpoint customer number followed by :CONTCT_2. The company's transfer creates that record before the relationship, through Add/Update NCR Counterpoint Customer TO iPaaS.com, when Contact 2 has a name; when there is no such record, the collection's mapping filter skips the relationship, or stops the company's transfer when Contact 2 is designated Super User.
Type — Dynamic Formula
Source:
// Adobe Commerce/Magento 2 pre-creates only relationship types containing "user" before assigning them to the company.
var designation = GetCustomField_CPHive(Parent, "USER_CONTCT_2_TYP");
if (designation == null) { return "User"; }
var code = designation.ToString().Trim().ToUpper().Replace(" ", "");
if (code == "S" || code == "SUPERUSER") { return "Super User"; }
if (code == "A" || code == "ADMIN") { return "Admin User"; }
return "User";
Destination: Type
This is a recommended field. Downstream storefronts decide each contact's role from it. The formula sets Contact 2's role from the NCR Counterpoint custom field USER_CONTCT_2_TYP, ignoring capitalization and spaces:
S or SUPERUSER: Super User, the company's administrator.
A or ADMIN: Admin User.
Any other value, including ! (Counterpoint's no-selection value), or no value: User.
Contact 2 becomes the Super User only when it is designated so; otherwise Contact 1 is, when it is untyped or designated Super User and has been transferred (see the Type mapping of Add/Update NCR Counterpoint Company Contact 1 Relationship TO iPaaS.com for companies with neither).
Every type contains the word User because Adobe Commerce/Magento 2 creates a contact's account ahead of the company only for relationships whose type contains that word, then assigns every related contact to the company; subscribers or their MiSP who change these values should keep that word. Adobe Commerce/Magento 2 assigns an Admin User to the company as an ordinary company user; only the Super User becomes the company's administrator there.
IsPrimary — Static
Source: false · Destination: IsPrimary
This is an optional field. Marks Contact 2's relationship as not the company's primary contact. The value is fixed, because Contact 1 is always the primary contact.
Error Handling
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.
The coded errors this family raises for a company's contacts:
CRPT-BIZL-1005: a contact could not be transferred to iPaaS.com as a customer, so the company was not written. Check the contact's name and email address.
CRPT-VALD-1012: both contacts are designated Super User. Designate exactly one.
CRPT-VALD-1013: Contact 1 has a type but no contact is designated Super User. Designate Contact 1 or Contact 2 as S.
CRPT-VALD-1014: the Super User contact, designated or by default, has no email address of its own. Enter it in Email 1 (Contact 1) or Email 2 (Contact 2).
CRPT-BIZL-1008: the designated Super User contact was not sent to iPaaS.com. Check that the contact has a name in Counterpoint and that the company passes the mapping filter of Add/Update NCR Counterpoint Customer TO iPaaS.com.
Each message names the Counterpoint customer. Once the data is corrected in Counterpoint, the company transfers again with its next reported change, or through a Manual Sync of Add/Update NCR Counterpoint Company TO iPaaS.com.
Testing & Validation
Work through these steps in a test environment before relying on the collections in production.
Confirm that no existing customer carries the marker, then set both Customer-as-company Field and Customer-as-company Field Value on the test subscription. Where the marker or the contact type fields are new custom fields, add them to Counterpoint and regenerate the CPHive data dictionary cache first.
If the company's category is not already in iPaaS.com, run a Manual Sync of Add/Update NCR Counterpoint Customer Category TO iPaaS.com with the Counterpoint category code.
Create a new Counterpoint customer with the company marker set and E-commerce customer not yet flagged. Give it an Email 1, a Phone 1, a First name and Last name, a complete billing address, a category, a name in Contact 1 and Contact 2, and Contact 2's own Email 2.
Flag it as an e-commerce customer. With CPWebhooks and the Customer subscriptions enabled, that save transfers the company; otherwise run a Manual Sync of Add/Update NCR Counterpoint Company TO iPaaS.com with its customer number.
In iPaaS.com, confirm that the company exists with its billing and ship-to addresses and its category; that each contact exists with its own first and last name and an email address starting CONTCT_1: or CONTCT_2:; and that the company's relationships show one Super User, and the other contact as Admin User or User.
Change the company in Counterpoint, for example its Phone 1, and confirm that the change updates the same iPaaS.com company rather than creating a second one.
Where the contact type fields are in use, designate both contacts Super User on the test company and confirm that the transfer stops with CRPT-VALD-1012 at Dashboard / Integration Monitoring / Error Logs; then designate exactly one.
Additional Notes
Companies are not written to Counterpoint: companies transfer from Counterpoint to iPaaS.com only. A company is never written back to Counterpoint, and a company contact is not written back while it keeps its link to Counterpoint; do not remove a contact's NCR Counterpoint external ID.
At the time this documentation was written:
Contacts are kept by position: Contact 1 and Contact 2 are the same iPaaS.com customer records whoever holds them. Entering a different person as a contact in Counterpoint turns the existing contact record into the new person, and where the Adobe Commerce/Magento 2 customer Outbound Data Flow is on, the storefront account linked to the record passes to the new person, with its login and order history (for Contact 2 with that flow off, the account stays the previous person's). For Contact 2, remove the previous contact first, as described in the next item, then enter the new person; for Contact 1, see the Email 1 note at the end of that item.
Clearing a contact removes nothing: its iPaaS.com customer record, its relationship to the company and its storefront company membership all stay, and in Adobe Commerce/Magento 2 the person can still buy for the company. To remove Contact 2:
If it is the Super User, first make Contact 1 the Super User and change the company's administrator in the storefront.
Remove the person from the company in the storefront.
In Counterpoint, clear the company's marker, then Contact 2 (and any custom field that repeats it), Email 2 and Contact 2's type.
In iPaaS.com, remove the contact's relationship on the company, then delete its customer record. Keep this relationship-first order: a relationship to a deleted customer stops the company from transferring to Adobe Commerce/Magento 2. Where customer deletions are sent to Adobe Commerce/Magento 2, deleting the record also deletes the shopper's account, even with its Adobe Commerce/Magento 2 external ID removed; to keep the account, turn off the customer/deleted trigger in the Adobe Commerce/Magento 2 subscription's Outbound Data Flows, wait a minute, delete the record, and turn the trigger back on a few minutes later.
Set the marker again, in a save that keeps the company an e-commerce customer with its Email 1.
Contact 1 holds the company's Email 1: entering a different person as Contact 1 changes Email 1 and stops the company's transfers to Adobe Commerce/Magento 2 until Contact 1 is put back.
Keep Email 1 unchanged once a company is in Adobe Commerce/Magento 2: changing it stops the company's transfers there until it is put back.
Moving the Super User changes iPaaS.com only: changing which contact is designated Super User in Counterpoint changes the relationship types in iPaaS.com, but a storefront that already created the company, such as Adobe Commerce/Magento 2, keeps its existing administrator. Change the administrator there as well.
Clearing the marker pauses a company: while a customer's company exists in iPaaS.com, clearing its marker stops its Counterpoint changes altogether. They are not routed to the company, and the Customer collection's mapping filter holds the customer back.
Category changes are added, not replaced: when a company's category changes in Counterpoint, iPaaS.com adds the new category and keeps the old one, and a company's last category cannot be removed. The company's Adobe Commerce/Magento 2 customer group follows its current category: the Adobe Commerce/Magento 2 company collection takes the category named by the company's Department, which this collection sets to the current category code on every transfer. An Adobe Commerce/Magento 2 subscription still on the earlier mapping, which takes the first category, keeps the company in its first group until that mapping is updated.
These and other runtime behaviors are documented in NCR Counterpoint Known Limitations.
Related Documents
Related Mapping Documentation