iPaaS.com to NCR Counterpoint Deposit Refund Mapping Documentation

This mapping collection writes deposit refunds from iPaaS.com into NCR Counterpoint. When a customer is given back a deposit that was taken against an order whose lines have not yet been released, this collection records the refund in Counterpoint — the ticket it is created under, the store, station, drawer and user it is attributed to, the customer it is linked to, the billing and shipping details it carries, the tax recorded against it, and the amounts that take the deposit back off the original order.

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.

Important: these two collections are complementary rather than alternatives, and the mapping filters are what divide the refunds between them, so both are normally enabled together and neither transfers the other's refunds as shipped. Subscribers or their MiSP should review both collections' filters together before changing either — a refund that both filters accept is written twice, and a refund that neither accepts is not written at all.

Mapping Filter

Filter Description.

A refund is written to NCR Counterpoint by this collection only when the iPaaS.com transaction is a Validated Return and none of the originating order's lines have already been released. Refunds against an order whose lines have been released are not deposit refunds and are handled by Add NCR Counterpoint Item Refund FROM iPaaS.com instead — see Duplicate or Conflicting Collections below. Subscribers who relax this filter should be aware that the two collections divide the work between them on exactly this test, so widening one without narrowing the other allows the same refund to be written twice.

Source: "MAIN" · Destination: STR_ID

This is a required field — NCR Counterpoint rejects the record without it. A refund is recorded against a store, and this mapping supplies the store on every transfer; the value must be a store configured in your own Counterpoint installation. Because it is a static value, every refund is attributed to whichever single store is set here, whatever the order it reverses was placed against.

Counterpoint requires a store to be present, but it does not check the value against the stores configured in your installation as the refund transfers: a store that is not configured is accepted by the transfer and stored, and then fails later, when the refund is posted or used by another Counterpoint function, rather than being reported as a transfer error. Subscribers or their MiSP should confirm the store exists in Counterpoint before enabling this collection.

Placeholder value — replace during implementation: "MAIN" is an example store id, not a Counterpoint default. Replace it with the id of the store the refunds should be recorded in, taken from your own Counterpoint installation, before enabling this collection. Subscribers running more than one store should consider whether a fixed value is correct for their reporting, and replace it with a formula that derives the store if not.

Source: "1" · Destination: STA_ID

This is a required field — NCR Counterpoint rejects the record without it. A refund is recorded at a station, and this mapping supplies the station on every transfer; the value must be a station configured in your own Counterpoint installation. It records which point-of-sale station the refund is entered at. Because it is a static value, every refund is attributed to the same station.

Counterpoint requires a station to be present, but it does not check the value against the stations configured in your installation as the refund transfers: a station that is not configured is accepted by the transfer and stored, and then fails later, when the refund is posted or used by another Counterpoint function, rather than being reported as a transfer error. Subscribers or their MiSP should confirm the station exists in Counterpoint before enabling this collection.

Placeholder value — replace during implementation: "1" is an example station id, not a Counterpoint default. Despite being a single character it identifies a station rather than selecting an option, so it is not a value to leave as shipped. Replace it with a station id from your own Counterpoint installation before enabling this collection, and make sure it is one that belongs to the store set on the STR_ID mapping above.

Source: "1" · Destination: DRW_ID

This is a recommended field, and where it is mapped the value must be a drawer configured in your own Counterpoint installation. Counterpoint accepts the refund without it, but a refund is normally recorded against a drawer, and this mapping supplies the drawer on every transfer. It records which cash drawer the refund is taken from, which is what ties the money going out to the drawer that has to account for it. Because it is a static value, every refund is attributed to the same drawer.

Counterpoint does not check the value against the drawers configured in your installation as the refund transfers: a drawer that is not configured is accepted by the transfer and stored, and then fails later, when the refund is posted or used by another Counterpoint function, rather than being reported as a transfer error. Subscribers or their MiSP should confirm the drawer exists in Counterpoint before enabling this collection.

Placeholder value — replace during implementation: "1" is an example drawer id, not a Counterpoint default. Despite being a single character it identifies a drawer rather than selecting an option, so it is not a value to leave as shipped. Replace it with a drawer id from your own Counterpoint installation before enabling this collection, and make sure it is one that belongs to the station and store set on the mappings above. Subscribers who reconcile drawers should confirm that refunds arriving from iPaaS.com are expected in the drawer set here, since they arrive without anyone at the station.

Source: "BC" + TransactionNumber · Destination: TKT_NO

This is a required field — NCR Counterpoint rejects the record without it. It is the ticket number the refund is created with, and it is what distinguishes the refund from tickets entered directly in NCR Counterpoint. The formula takes the iPaaS.com transaction number and puts a two-character prefix in front of it.

Subscribers changing the prefix must change it in the same way on every collection that writes a ticket number, and must keep it at two characters, because the prefix becomes part of the ticket number Counterpoint stores and matches on. Placeholder value — replace during implementation: "BC" is an example prefix, not a Counterpoint default. It was chosen for a specific pairing rather than as a general-purpose value. Replace it with a prefix that suits your own Counterpoint installation before enabling this collection, keeping it to two characters, and apply the same prefix consistently across every collection that writes a ticket number.

Source: "Z" · Destination: USR_ID

This is a recommended field, and where it is mapped the value must be a Counterpoint user that exists in your own installation. Counterpoint accepts the refund without it, but it records who entered the refund, and Counterpoint attributes the refund to this user. Because it is a static value, every refund arriving from iPaaS.com is recorded against the same user rather than against a person at the till, which is what subscribers will want: it makes refunds that came from the website identifiable as such.

Counterpoint does not check the value against the users configured in your installation as the refund transfers: a user that does not exist is accepted by the transfer and stored, and then fails later, when the refund is posted or used by another Counterpoint function, rather than being reported as a transfer error. Subscribers or their MiSP should confirm the user exists in Counterpoint before enabling this collection.

Placeholder value — replace during implementation: "Z" is an example user id, not a Counterpoint default. Despite being a single character it identifies a user rather than selecting an option, so it is not a value to leave as shipped. Replace it with a user id from your own Counterpoint installation before enabling this collection. Subscribers should consider creating a user dedicated to transfers from iPaaS.com rather than reusing a real person's id, so that refunds arriving automatically are not attributed to staff who did not enter them.

Source: return await CustomerFromEmailAsync(EmailAddress); · Destination: CUST_NO

This is an optional field, but where it supplies a value that value must be an existing Counterpoint customer. It links the refund to a customer in NCR Counterpoint. Rather than using an id, the formula searches Counterpoint for a customer whose e-mail address matches the one on the iPaaS.com transaction. Where more than one customer shares that address, a customer flagged as an e-commerce customer is preferred; if none of the matches is flagged that way, the first match is used.

This matching is a search, not a transfer: a customer who has never reached Counterpoint is not created here, so subscribers who want refunds linked to real customers should confirm customers are transferring to Counterpoint before enabling this collection.

Where nothing matches, no customer number is supplied and the record is created without a customer link. The transfer does not fail, and it does not pull the customer across. Because the match is made on the email address alone, this is the ordinary path for a guest or otherwise unrecognised purchaser rather than an edge case. Subscribers who want these records attributed to real customers should have customers transferring to Counterpoint before enabling this collection.

Because the match is made on e-mail address, subscribers should be aware of what that implies. Customers who transact without an address, or under a different address from the one held in Counterpoint, are not matched. Where several people share one address, the refund may link to whichever of them the search returns. Subscribers who key customers on something other than e-mail should replace this formula with one that matches on the field they actually use.

Source: "WEBSITE" · Destination: TAX_OVRD_REAS

This is a recommended field, and where it is mapped the value must be a reason code configured in your own Counterpoint installation. Counterpoint accepts the refund without it, but the mapping supplies a value on every transfer, and it is what tells NCR Counterpoint why the tax on the refund was overridden. The refund carries the tax from the iPaaS.com transaction rather than letting Counterpoint calculate it, which is what makes it an override and is why a reason accompanies it.

Counterpoint does not check the value against the reason codes configured in your installation as the refund transfers: a reason code that is not configured is accepted by the transfer and stored, and then fails later, when the refund is posted or used by another Counterpoint function, rather than being reported as a transfer error. Subscribers or their MiSP should confirm the reason code exists in Counterpoint before enabling this collection.

Placeholder value — replace during implementation: "WEBSITE" is an example reason code, not a Counterpoint default. Replace it with a tax override reason code configured in your own Counterpoint installation before enabling this collection — an unconfigured reason code is accepted and stored rather than rejected, which is what makes leaving the example in place easy to miss. Subscribers should set up a reason code that identifies tax overrides as having come from iPaaS.com, so that overridden tax on refunds is distinguishable in reporting from tax overridden by staff at the till.

Source: "0" · Destination: TIMES_PRTD

This is a recommended field. Counterpoint accepts the refund without it and records 0 instead, so it should be mapped for accurate data. It counts how many times the refund has been printed. Zero is the standard starting value and is correct for a refund that has just been created and never printed, so this is a genuine Counterpoint starting value rather than an example and does not need changing for a typical install — the static supplies the same value Counterpoint would apply on its own.

Because it is a static value, every refund arrives showing as never printed. Counterpoint maintains the count from that point on.

Source: "WEBSITE" · Destination: TAX_EXEMPT_NO

This is a recommended field. Counterpoint accepts the refund without it, but where tax is overridden and no tax is charged, a tax exemption number alongside the override reason on the TAX_OVRD_REAS mapping above is what records why. This mapping supplies one on every transfer.

Placeholder value — replace during implementation: "WEBSITE" is an example value, not a Counterpoint default. Replace it with a value that suits your own Counterpoint installation before enabling this collection.

Unlike the override reason, this is recorded rather than validated — it is a number Counterpoint stores against the refund, not a code selected from a configured list, and there is no restriction on its format or contents. Because a static value is used, every refund carries the same exemption number rather than the exempting customer's own. Subscribers who need real exemption numbers recorded against refunds — for tax reporting, or where genuinely tax-exempt customers are involved — should replace this mapping with a formula that supplies the customer's number, and should not rely on the shipped value to identify an exempt sale.

Source: ((TaxAmount < 0) && (Coalesce((string)(FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "Region")),(string)(FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "Region"))) == "Tennessee") ? "MEMTN" : (((TaxAmount < 0) && !(Coalesce((string)(FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "Region")),(string)(FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "Region"))) == "Tennessee") ? "MEMTN" : "MEMTN"))) · Destination: TAX_COD

This is a recommended field, and it is required in practice. The transfer succeeds without it and Counterpoint accepts the refund — but it is the tax code the refund is recorded under in NCR Counterpoint, so it should be mapped for accurate tax reporting, and the value must be a tax code configured in your own Counterpoint installation.

Counterpoint does not check the value against the tax codes configured in your installation as the refund transfers: a tax code that is not configured is accepted by the transfer and stored, and then fails later, when the refund is posted or used by another Counterpoint function, rather than being reported as a transfer error. Subscribers or their MiSP should confirm the tax code exists in Counterpoint before enabling this collection.

The formula is written as a decision with three branches: a taxed refund whose customer is in a named state, a taxed refund whose customer is anywhere else, and an untaxed refund. It reads the region from the primary shipping address, falling back to the primary billing address where there is no shipping one.

As shipped, all three branches supply the same tax code, so in its current form the formula returns one code for every refund regardless of tax or region. The branching exists so subscribers can give each situation its own code without rebuilding the logic — the structure is there to be filled in, and until it is, the region test has no effect on the result.

Placeholder value — replace during implementation: the state name and the tax code in this formula are examples drawn from one installation, not Counterpoint defaults. Replace them with the states and tax codes your own Counterpoint installation uses before enabling this collection, and give each branch the code that belongs to it rather than leaving all three the same. Subscribers who operate in more than the two tax situations the formula allows for will need to extend it; subscribers whose tax does not vary by region can reduce it to a single code.

Source: Truncate((FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "Company") == "" ? (FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "FirstName") + " " + FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "LastName")) : (FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "Company"))),40) · Destination: BILL_NAM

This is an optional field. It is the name the refund is billed to. Where the customer's primary billing address carries a company, the company is used; otherwise the first and last names are joined together. This follows how NCR Counterpoint itself decides a billing name, and it works together with the BILL_NAM_TYP mapping below, which records which of the two was chosen.

Counterpoint allows a limited amount of space for this field, so the formula trims the result to 40 characters to fit. A refund whose iPaaS.com transaction has no primary billing address transfers with the field empty.

Source: Truncate(FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "FirstName"),15) · Destination: BILL_FST_NAM

This is an optional field. It carries the first name from the customer's primary billing address. Counterpoint allows a limited amount of space for this field, so the formula trims the value to 15 characters to fit; a longer first name is shortened rather than rejected. A refund whose iPaaS.com transaction has no primary billing address transfers with the field empty.

This is written alongside BILL_NAM above rather than instead of it — Counterpoint holds the billing name both as a single line and as separate parts, and the two are populated independently.

Source: Truncate(FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "LastName"),25) · Destination: BILL_LST_NAM

This is an optional field. It carries the last name from the customer's primary billing address. Counterpoint allows a limited amount of space for this field, so the formula trims the value to 25 characters to fit; a longer last name is shortened rather than rejected. A refund whose iPaaS.com transaction has no primary billing address transfers with the field empty.

This is written alongside BILL_NAM above rather than instead of it — Counterpoint holds the billing name both as a single line and as separate parts, and the two are populated independently.

Source: Truncate(FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "Address2"),40) · Destination: BILL_ADRS_2

This is an optional field. It carries the Address2 of the customer's primary billing address onto the refund, so the refund in NCR Counterpoint shows the same billing details as the order it reverses. Counterpoint allows a limited amount of space for this field, so the formula trims the value to 40 characters to fit; a longer value is shortened rather than rejected, and the trimmed part is not recorded anywhere. A refund whose iPaaS.com transaction has no primary billing address, or whose address leaves this field empty, transfers with the field empty.

Source: Truncate(FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "Address3"),40) · Destination: BILL_ADRS_3

This is an optional field. It carries the Address3 of the customer's primary billing address onto the refund, so the refund in NCR Counterpoint shows the same billing details as the order it reverses. Counterpoint allows a limited amount of space for this field, so the formula trims the value to 40 characters to fit; a longer value is shortened rather than rejected, and the trimmed part is not recorded anywhere. A refund whose iPaaS.com transaction has no primary billing address, or whose address leaves this field empty, transfers with the field empty.

Source: Truncate(FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "City"),20) · Destination: BILL_CITY

This is an optional field. It carries the City of the customer's primary billing address onto the refund, so the refund in NCR Counterpoint shows the same billing details as the order it reverses. Counterpoint allows a limited amount of space for this field, so the formula trims the value to 20 characters to fit; a longer value is shortened rather than rejected, and the trimmed part is not recorded anywhere. A refund whose iPaaS.com transaction has no primary billing address, or whose address leaves this field empty, transfers with the field empty.

Source: Truncate(FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "PostalCode"),15) · Destination: BILL_ZIP_COD

This is an optional field. It carries the PostalCode of the customer's primary billing address onto the refund, so the refund in NCR Counterpoint shows the same billing details as the order it reverses. Counterpoint allows a limited amount of space for this field, so the formula trims the value to 15 characters to fit; a longer value is shortened rather than rejected, and the trimmed part is not recorded anywhere. A refund whose iPaaS.com transaction has no primary billing address, or whose address leaves this field empty, transfers with the field empty.

Source: Truncate(FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "Country"),20) · Destination: BILL_CNTRY

This is an optional field. It carries the Country of the customer's primary billing address onto the refund, so the refund in NCR Counterpoint shows the same billing details as the order it reverses. Counterpoint allows a limited amount of space for this field, so the formula trims the value to 20 characters to fit; a longer value is shortened rather than rejected, and the trimmed part is not recorded anywhere. A refund whose iPaaS.com transaction has no primary billing address, or whose address leaves this field empty, transfers with the field empty.

Source: (FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "Company") == "" ? "P" : "B") · Destination: BILL_NAM_TYP

This is a recommended field. Allowed values: P and B. Counterpoint accepts the refund without it and records B instead, so it should be mapped for accurate data — an unmapped value marks every refund as billed to a business regardless of the name actually stored. It records whether the refund is billed to a person or to a business, which is what tells NCR Counterpoint how to read the billing name written by the BILL_NAM mapping above.

The formula derives the value from the same source as that mapping rather than from a separate field: where the primary billing address carries a company, the refund is marked as billed to a business; where it does not, the refund is marked as billed to a person and the name is the customer's own. This keeps the two consistent, which matters because Counterpoint treats them as a pair — a refund marked as billed to a business but carrying a person's name, or the reverse, displays and reports inconsistently. Subscribers replacing either mapping should keep both derived from the same source.

Source: Truncate((FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "Company") == "" ? (FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "FirstName") + " " + FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "LastName")) : (FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "Company"))),40) · Destination: SHIP_NAM

This is an optional field. It is the name the refund is shipped to. Where the customer's primary shipping address carries a company, a company name is used; otherwise the first and last names from the shipping address are joined together. This follows how NCR Counterpoint itself decides a shipping name, and it works together with the SHIP_NAM_TYP mapping below, which records which of the two was chosen.

Counterpoint allows a limited amount of space for this field, so the formula trims the result to 40 characters to fit. A refund whose iPaaS.com transaction has no primary shipping address transfers with the field empty.

Subscribers should be aware of one detail before relying on this mapping as shipped. The formula tests the shipping address for a company, but when it finds one it supplies the company from the billing address rather than the shipping address. Where the two addresses carry the same company this makes no difference, and where a customer ships to a business but bills to a person the field is left empty rather than showing the shipping company. Subscribers whose shipping and billing companies can differ should replace the mapping with one that reads the shipping company in both places, and should validate the result in a staging environment before relying on it in production.

Source: Truncate(FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "FirstName"),15) · Destination: SHIP_FST_NAM

This is an optional field. It carries the first name from the customer's primary shipping address. Counterpoint allows a limited amount of space for this field, so the formula trims the value to 15 characters to fit; a longer first name is shortened rather than rejected. A refund whose iPaaS.com transaction has no primary shipping address transfers with the field empty.

This is written alongside SHIP_NAM above rather than instead of it — Counterpoint holds the shipping name both as a single line and as separate parts, and the two are populated independently.

Source: Truncate(FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "LastName"),25) · Destination: SHIP_LST_NAM

This is an optional field. It carries the last name from the customer's primary shipping address. Counterpoint allows a limited amount of space for this field, so the formula trims the value to 25 characters to fit; a longer last name is shortened rather than rejected. A refund whose iPaaS.com transaction has no primary shipping address transfers with the field empty.

This is written alongside SHIP_NAM above rather than instead of it — Counterpoint holds the shipping name both as a single line and as separate parts, and the two are populated independently.

Source: Truncate(FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "Address2"),40) · Destination: SHIP_ADRS_2

This is an optional field. It carries the Address2 of the customer's primary shipping address onto the refund, so the refund in NCR Counterpoint shows the same shipping details as the order it reverses. Counterpoint allows a limited amount of space for this field, so the formula trims the value to 40 characters to fit; a longer value is shortened rather than rejected, and the trimmed part is not recorded anywhere. A refund whose iPaaS.com transaction has no primary shipping address, or whose address leaves this field empty, transfers with the field empty.

Source: Truncate(FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "Address3"),40) · Destination: SHIP_ADRS_3

This is an optional field. It carries the Address3 of the customer's primary shipping address onto the refund, so the refund in NCR Counterpoint shows the same shipping details as the order it reverses. Counterpoint allows a limited amount of space for this field, so the formula trims the value to 40 characters to fit; a longer value is shortened rather than rejected, and the trimmed part is not recorded anywhere. A refund whose iPaaS.com transaction has no primary shipping address, or whose address leaves this field empty, transfers with the field empty.

Source: Truncate(FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "City"),20) · Destination: SHIP_CITY

This is an optional field. It carries the City of the customer's primary shipping address onto the refund, so the refund in NCR Counterpoint shows the same shipping details as the order it reverses. Counterpoint allows a limited amount of space for this field, so the formula trims the value to 20 characters to fit; a longer value is shortened rather than rejected, and the trimmed part is not recorded anywhere. A refund whose iPaaS.com transaction has no primary shipping address, or whose address leaves this field empty, transfers with the field empty.

Source: Truncate(FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "PostalCode"),15) · Destination: SHIP_ZIP_COD

This is an optional field. It carries the PostalCode of the customer's primary shipping address onto the refund, so the refund in NCR Counterpoint shows the same shipping details as the order it reverses. Counterpoint allows a limited amount of space for this field, so the formula trims the value to 15 characters to fit; a longer value is shortened rather than rejected, and the trimmed part is not recorded anywhere. A refund whose iPaaS.com transaction has no primary shipping address, or whose address leaves this field empty, transfers with the field empty.

Source: Truncate(FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "Country"),20) · Destination: SHIP_CNTRY

This is an optional field. It carries the Country of the customer's primary shipping address onto the refund, so the refund in NCR Counterpoint shows the same shipping details as the order it reverses. Counterpoint allows a limited amount of space for this field, so the formula trims the value to 20 characters to fit; a longer value is shortened rather than rejected, and the trimmed part is not recorded anywhere. A refund whose iPaaS.com transaction has no primary shipping address, or whose address leaves this field empty, transfers with the field empty.

Source: (FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "Company") == "" ? "P" : "B") · Destination: SHIP_NAM_TYP

This is a recommended field. Allowed values: P and B. Counterpoint accepts the refund without it and records B instead, so it should be mapped for accurate data — an unmapped value marks every refund as shipped to a business regardless of the name actually stored. It records whether the refund is shipped to a person or to a business, which is what tells NCR Counterpoint how to read the shipping name written by the SHIP_NAM mapping above.

The formula derives the value from the primary shipping address rather than from a separate field: where that address carries a company, the refund is marked as shipped to a business; where it does not, the refund is marked as shipped to a person. This keeps the marker and the name consistent, which matters because Counterpoint treats them as a pair. Subscribers replacing either mapping should keep both derived from the same source.

Source: Truncate(FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "Region"), 10) · Destination: BILL_STATE

This is an optional field. It carries the state or region of the customer's primary billing address. Counterpoint allows a limited amount of space for this field, so the formula trims the value to 10 characters to fit. This is shorter than the other address fields and short enough to matter: a region written in full rather than abbreviated may be shortened, so subscribers whose iPaaS.com data holds full region names should confirm the trimmed result is still the value Counterpoint expects, and supply an abbreviation instead if it is not. A refund whose iPaaS.com transaction has no primary billing address transfers with the field empty.

Source: Truncate(FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "Region"), 10) · Destination: SHIP_STATE

This is an optional field. It carries the state or region of the customer's primary shipping address. Counterpoint allows a limited amount of space for this field, so the formula trims the value to 10 characters to fit. This is shorter than the other address fields and short enough to matter: a region written in full rather than abbreviated may be shortened, so subscribers whose iPaaS.com data holds full region names should confirm the trimmed result is still the value Counterpoint expects, and supply an abbreviation instead if it is not. A refund whose iPaaS.com transaction has no primary shipping address transfers with the field empty.

The TAX_COD mapping above reads the same shipping region to decide the tax code, so subscribers changing how regions are supplied should check the effect on both.

Source: Truncate(FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "Address1"), 40) · Destination: BILL_ADRS_1

This is an optional field. It carries the Address1 of the customer's primary billing address onto the refund, so the refund in NCR Counterpoint shows the same billing details as the order it reverses. Counterpoint allows a limited amount of space for this field, so the formula trims the value to 40 characters to fit; a longer value is shortened rather than rejected, and the trimmed part is not recorded anywhere. A refund whose iPaaS.com transaction has no primary billing address, or whose address leaves this field empty, transfers with the field empty.

Source: Truncate(FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "Address1"), 40) · Destination: SHIP_ADRS_1

This is an optional field. It carries the Address1 of the customer's primary shipping address onto the refund, so the refund in NCR Counterpoint shows the same shipping details as the order it reverses. Counterpoint allows a limited amount of space for this field, so the formula trims the value to 40 characters to fit; a longer value is shortened rather than rejected, and the trimmed part is not recorded anywhere. A refund whose iPaaS.com transaction has no primary shipping address, or whose address leaves this field empty, transfers with the field empty.

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

This is an optional field. It carries the e-mail address from the iPaaS.com transaction onto the refund, so the refund records where a confirmation would be sent. Counterpoint allows a limited amount of space for this field, so the formula trims the value to 50 characters to fit; a longer address is shortened rather than rejected, which leaves it stored but no longer usable for contacting the customer.

This is the same address the CUST_NO mapping above searches on, so a refund that failed to match a customer still records the address it tried to match. A transaction with no e-mail address transfers with the field empty.

Source: return await GetExternalIdAsync(ParentId, "Transaction", SpaceportSystemId); · Destination: ORIG_ORD_DOC_ID

This is a recommended field. Counterpoint accepts the refund without it, but it is what ties the refund to the deposit it returns, and a refund without it is not connected to the order it reverses — so it should be mapped. It links the refund back to the original order in NCR Counterpoint by looking up the Counterpoint document that the iPaaS.com order was previously transferred to.

This is a lookup, not a transfer: the original order is not sent to Counterpoint as a prerequisite. The order must already have reached Counterpoint for the link to resolve, which in normal operation it will have, since the deposit being refunded was taken against it. Subscribers should nonetheless be aware that a refund whose original order never reached Counterpoint has nothing to link to, and should confirm orders are transferring successfully before enabling this collection.

The Mapping Filter uses the same original order to decide whether the refund belongs here at all — only returns whose original order has no released lines are treated as deposit refunds.

Source: Total * -1 · Destination: ORD_DEP_AMT_REFUNDED

This is a recommended field. Counterpoint accepts the refund without it and records 0 instead, so it should be mapped for accurate data — it is one of the amounts that records the deposit being given back, and a refund left at zero here does not reduce the deposit. It records the deposit amount refunded against the original order. The formula negates the iPaaS.com transaction total, because a refund returns money and Counterpoint records money going out as a negative amount.

This is one of five mappings in this collection that write the same negated total to a different Counterpoint field. Counterpoint tracks a deposit in several places — against the order and against the document, as both an amount refunded and a net change — and each has to be told about the refund for the deposit to come out right. Subscribers replacing any of them should replace all five consistently, since a refund that reduces one but not the others leaves the deposit disagreeing with itself.

Because the total is used whole, this collection returns a deposit in full. The parent transfer is reported as an error if the refund payment amount does not equal the original order total, so a partial deposit refund does not transfer as a smaller amount — it is reported as an error instead.

Source: Total * -1 · Destination: ORD_DEP_NET_CHANGE

This is a recommended field. Counterpoint accepts the refund without it, but it is one of the amounts that records the deposit being given back, and a refund that omits it does not record the deposit coming off the order — so it should be mapped. It records the net change to the deposit held against the original order. The formula negates the iPaaS.com transaction total, because a refund returns money and Counterpoint records money going out as a negative amount.

This is one of the five mappings described on the ORD_DEP_AMT_REFUNDED mapping above, all writing the same negated total to a different Counterpoint field. The amount refunded and the net change are recorded separately because Counterpoint distinguishes what was returned from the effect on the balance held; on a full refund they are the same figure. Subscribers replacing any of the five should replace all of them consistently.

Source: Total * -1 · Destination: DEP_AMT_REFUNDED

This is a recommended field. Counterpoint accepts the refund without it and records 0 instead, so it should be mapped for accurate data — it is one of the amounts that records the deposit being given back, and a refund left at zero here does not reduce the deposit. It records the deposit amount refunded on the document. The formula negates the iPaaS.com transaction total, because a refund returns money and Counterpoint records money going out as a negative amount.

This is the document-level counterpart of the ORD_DEP_AMT_REFUNDED mapping above, and one of the five mappings described there. Counterpoint tracks the deposit both against the order and against the document that carries it, and both have to agree. Subscribers replacing any of the five should replace all of them consistently.

Source: Total * -1 · Destination: DEP_NET_CHANGE

This is a recommended field. Counterpoint accepts the refund without it, but it is one of the amounts that records the deposit being given back, and a refund that omits it does not record the deposit coming off the document — so it should be mapped. It records the net change to the deposit on the document. The formula negates the iPaaS.com transaction total, because a refund returns money and Counterpoint records money going out as a negative amount.

This is the document-level counterpart of the ORD_DEP_NET_CHANGE mapping above, and one of the five mappings described on the ORD_DEP_AMT_REFUNDED mapping. Subscribers replacing any of the five should replace all of them consistently.

Source: Total * -1 · Destination: DOC_DEP_REFUNDED

This is a recommended field. Counterpoint accepts the refund without it and records 0 instead, so it should be mapped for accurate data — it is one of the amounts that records the deposit being given back, and a refund left at zero here does not reduce the deposit. It records the deposit refunded on the document. The formula negates the iPaaS.com transaction total, because a refund returns money and Counterpoint records money going out as a negative amount.

This is the last of the five mappings described on the ORD_DEP_AMT_REFUNDED mapping above, all writing the same negated total to a different Counterpoint field. Subscribers replacing any of them should replace all of them consistently.

The refund's payment side is carried by the child collection Add/Update NCR Counterpoint Deposit Refund Payment FROM iPaaS.com, which records the tender the money is returned through. These mappings record the deposit coming off the order; that collection records where the money goes.

Parent: Add NCR Counterpoint Deposit Refund FROM iPaaS.com.

Source: "C" · Destination: PMT_LIN_TYP

This is a recommended field. It tells NCR Counterpoint what kind of payment line is being written. Counterpoint accepts the record without it and records T instead, so it should be mapped for accurate data — leaving it unmapped describes the line as a different kind of payment from the one intended. The static value marks the line as a change line, which is what returns money to the customer rather than collecting it. This is correct for a refund: the parent collection writes a negative amount, and this field is what makes Counterpoint treat that amount as money going out.

This is a genuine Counterpoint constant rather than an example, so it does not need changing for a typical install. Changing it away from a change line would stop the refund paying the customer back.

Source: Lookup Translation: **CP Transaction Payment PAY_COD From iPaaS** · Destination: PAY_COD

This is a recommended field, and where it supplies a value that value must be a pay code configured in your own Counterpoint installation. It is the pay code that tells NCR Counterpoint which tender the money is being returned through. Counterpoint accepts the record without it, but a refund that arrives without a pay code has nothing recording where the money went, so it should be mapped. Rather than passing the iPaaS.com payment method straight through, this mapping runs it through a translation that converts each method into a Counterpoint pay code.

Counterpoint does not check the pay code against the pay codes configured in your installation as the payment transfers: a pay code that is not configured is accepted by the transfer and stored, and then fails later, when the refund is posted or used by another Counterpoint function, rather than being reported as a transfer error. Subscribers or their MiSP should confirm every pay code this translation can supply exists in Counterpoint before enabling this collection.

The translation ships with rows covering the payment methods commonly seen in practice. Most of them — the card brands, the online gateways, cash, and a catch-all — resolve to a single cash pay code, so out of the box almost every refund is returned as cash regardless of how the customer originally paid. Gift cards and store credits are the exception: two of the rows match on the payment method together with the gift card type behind it, sending gift cards to a gift card pay code and store credits to a store credit pay code. One further row sends an amount-due method to a receivables pay code.

Two things need attention before the first transfer.

Subscribers who want refunds returned to the original tender rather than all landing on one pay code should expand the translation so each method maps to its own Counterpoint pay code, rather than accepting the default that collapses them to cash.

Where a refund is returned to a gift card or store credit, the card itself is transferred to Counterpoint ahead of the refund if it is not already there, so the pay code has a card to resolve against.

Source: Amount · Destination: AMT

This is a recommended field. It is the amount being returned to the customer. Counterpoint accepts the record without it and records 0 instead, so it should be mapped for accurate data — an unmapped amount produces a payment line that returns nothing. The iPaaS.com payment amount is passed straight through with no formula, so the value Counterpoint receives is the value iPaaS.com holds.

The amount is expected to be negative on a refund, because it is money leaving rather than money collected. The parent collection checks this before the transfer runs: it raises an error if the payment amount, negated, does not equal the total of the order the refund is written against, and it raises an error if the payment was declined. The practical effect is that this collection handles refunds that return a deposit in full — a partial refund, or a refund whose payment amount disagrees with the original order total, is reported as an error rather than written as a short payment. Subscribers who need partial deposit refunds should be aware this is not what the shipped configuration does.

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.

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