iPaaS.com to NCR Counterpoint Item Refund Mapping Documentation

This mapping collection writes item refunds from iPaaS.com into NCR Counterpoint. It transfers the refund itself — the store, station and ticket number it is recorded under, the customer it is given back to, the bill-to and ship-to details, the shipping amount being returned, and the tax treatment the refund is recorded with. Only a refund that iPaaS.com holds as a validated return, and whose originating order already has at least one released line in Counterpoint, is transferred; refunds against an order with no released lines are handled by Add NCR Counterpoint Deposit Refund FROM iPaaS.com instead.

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.

Mapping Filter

Filter Description.

A transaction is transferred only when both tests pass. Its iPaaS.com type must be Validated Return — a return checked against the original sale rather than accepted on its own — and the order the return came from must already have at least one line released in Counterpoint. A refund that arrives before its original order has been released is not transferred by this collection.

Subscribers should not relax this filter to force a refund through. The refund's lines are linked back to the released sale lines they are returning, so a refund admitted before its original order has released lines has nothing in Counterpoint to link to, and fails on the link instead of on the filter.

Source: "MAIN" · Destination: STR_ID

This is a required field — NCR Counterpoint rejects the record without it. The store the refund is created in, and the value must be a store configured in your own Counterpoint installation. Every refund this collection transfers is attributed to the single store set here, whatever store the original sale was rung up in. 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 attributed to in your own Counterpoint installation before enabling this collection. Subscribers running more than one store should also consider whether a fixed store is correct for their reporting, and replace the Static with a formula if it is not.

Source: "1" · Destination: STA_ID

This is a required field — NCR Counterpoint rejects the record without it. The station the refund is recorded against, and the value must be a station configured in your own Counterpoint installation. Refunds arriving from iPaaS.com are not rung up at a physical station, so a fixed value stands in for one; every refund this collection transfers is recorded against whichever station is set here. 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. Replace it with a station id from your own Counterpoint installation before enabling this collection.

Source: "1" · Destination: DRW_ID

This is an optional field, but where it is mapped the value must be a drawer configured in your own Counterpoint installation. The drawer the refund is recorded against. As with the station above, a refund arriving from iPaaS.com has no physical drawer behind it, so a fixed value stands in for one. Counterpoint accepts the refund without a drawer, and it 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. Replace it with a drawer id from your own Counterpoint installation before enabling this collection.

Source: "BC" + TransactionNumber · Destination: TKT_NO

This is a required field — NCR Counterpoint rejects the record without it. The ticket number Counterpoint records for the refund. The formula takes the iPaaS.com transaction number and puts a fixed prefix in front of it, so that refunds arriving from iPaaS.com can be told apart from tickets entered at the point of sale.

Placeholder value — replace during implementation: the two-character prefix this formula adds is an example value, not a Counterpoint default — it was chosen for a Counterpoint-to-BigCommerce pairing and is carried by every refund ticket number this collection writes. Replace it with a prefix that suits your own Counterpoint installation, or remove it and map the transaction number straight through, before enabling this collection.

The same prefix is applied by the ticket-number mappings on the other transaction collections that write to Counterpoint. Subscribers changing it here should change it in those collections too, so that ticket numbers stay consistent across sales, orders, deposits and refunds.

Source: "Z" · Destination: USR_ID

This is an optional field, but where it is mapped the value must be a Counterpoint user that exists in your own installation. The point-of-sale user Counterpoint records as having entered the refund. Because no Counterpoint user is involved in a refund arriving from iPaaS.com, a fixed user stands in for one, which also makes refunds from iPaaS.com easy to pick out in Counterpoint reporting. Counterpoint accepts the refund without a user, and it 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. Replace it with a user id from your own Counterpoint installation before enabling this collection.

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. Links the refund to a Counterpoint customer. The formula searches Counterpoint for customers whose first email address matches the email address on the iPaaS.com transaction. Where more than one customer matches, a customer flagged in Counterpoint as an e-commerce customer is preferred; if none of the matches is flagged that way, the first match is used.

The match is made on the email address alone, so a customer who shops under a different address from the one on the transaction is not found. This collection does not transfer the customer to Counterpoint as a prerequisite; subscribers who want refunds attributed to real customers should have customers 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.

Source: FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "ShippingMethod") · Destination: SHIP_VIA_COD

This is an optional field, but where it is mapped the value must be a ship-via code configured in your own Counterpoint installation. The shipping method recorded on the refund. The formula takes the shipping method from the first address on the iPaaS.com transaction that is marked as the primary shipping address, and writes it straight through with no conversion. Where the transaction has no primary shipping address, the mapping supplies nothing.

Counterpoint's ship-via codes are configured per installation, and the shipping method names iPaaS.com carries come from the source system rather than from Counterpoint, so the two rarely use the same wording — which means this mapping as shipped routinely sends a value Counterpoint does not know. Counterpoint accepts the refund without a ship-via code, and it does not check the value against the ship-via codes configured in your installation as the refund transfers: a 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 whose iPaaS.com shipping methods do not already read as their own Counterpoint ship-via codes should replace this mapping with a Lookup Translation that pairs each shipping method with the matching code, and confirm those codes exist in Counterpoint before enabling this collection.

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. The reason code recorded against the tax override. Counterpoint accepts the record without it, but the SAL_HAS_TAX_OVRD mapping below tells Counterpoint the refund's tax has been overridden, and an override recorded with no reason against it leaves nothing in Counterpoint to explain why the tax was not calculated — so it should be mapped for accurate data.

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.

Source: "0" · Destination: TIMES_PRTD

This is a recommended field. Counts how many times the refund ticket has been printed. Counterpoint accepts the record without it and records 0 instead, so it should be mapped for accurate data. Zero is the standard starting value, and is correct for a refund that has just been created — Counterpoint maintains the count from there. This is a genuine starting value rather than an example, so it does not need changing for a typical install.

Source: "WEBSITE" · Destination: TAX_EXEMPT_NO

This is a recommended field. The tax exemption number recorded against the refund. Counterpoint accepts the record without it, but where the refund's tax is overridden and no tax is charged, the exemption number is what documents the exemption in Counterpoint — so it should be mapped for accurate data. Counterpoint does not check the format or the contents of this field, so any value satisfies it.

Placeholder value — replace during implementation: "WEBSITE" is an example tax exemption number, not a Counterpoint default. Replace it with a value that is meaningful in your own Counterpoint installation before enabling this collection. Because Counterpoint does not validate the contents, a wrong value here is recorded rather than rejected — which makes it easy to miss.

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 tax code Counterpoint records for the refund. The transfer succeeds without it and Counterpoint accepts the refund — but the integration supplies one on every refund and the tax child collection is written against it, so it should be mapped for accurate data, 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 a template that sorts each refund into one of three tax situations: a refund carrying tax whose region is the named home state, a refund carrying tax whose region is anywhere else, and a refund carrying no tax. The region is taken from the primary shipping address, falling back to the primary billing address where the transaction has no shipping address. Refunds carry negative tax amounts, which is why the test is for tax below zero rather than above it — this is the opposite of the equivalent mapping on the sale and order collections, and subscribers rewriting the formula need to keep that in mind.

As shipped, all three branches supply the same tax code, so the formula currently produces one tax code for every refund regardless of region. The branching is there so that subscribers can give each situation its own code; it does nothing until they do.

Placeholder value — replace during implementation: the home-state name and the tax codes in this formula are example values, not Counterpoint defaults. Replace them with the region and the tax codes configured in your own Counterpoint installation before enabling this collection. The matching mappings on the Add/Update NCR Counterpoint Item Refund Tax FROM iPaaS.com collection carry the same example values and must be changed to agree with whatever is set here.

Source: "A" · Destination: SAL_HAS_TAX_OVRD

This is a recommended field — a control mapping rather than a value. Counterpoint accepts the record without it and records ! instead, which is no override at all and leaves Counterpoint free to work the refund's tax out for itself, so it should be mapped for accurate data. Tells Counterpoint that the refund's tax has been overridden, and that the override is by amount rather than by tax-exempt status. Allowed values: ! for no override, E for tax exempt, and A for an override by amount.

The tax on a refund is decided by whichever system calculated it before iPaaS.com received it, and is carried through by the Add/Update NCR Counterpoint Item Refund Tax FROM iPaaS.com collection. Overriding by amount is what stops Counterpoint recalculating that tax against its own rules and arriving at a different figure from the one the customer was actually refunded. This is a genuine Counterpoint constant rather than an example, so it does not need changing for a typical install, but it works together with the TAX_OVRD_REAS and TAX_EXEMPT_NO mappings above — a subscriber who changes it should review those two as well.

Source: ShippingAmount · Destination: SAL_MISC_AMT_1

This is a required field — NCR Counterpoint rejects the record without it, raising Misc charge 1(SAL_MISC_AMT_1) is a required field. A refund carrying no shipping should therefore map a zero rather than leave the mapping off. The shipping amount being refunded, held to two decimal places, recorded in the first of Counterpoint's miscellaneous charge fields. Counterpoint offers several miscellaneous charge fields, and subscribers already using the first one for something else can carry the shipping amount on any of the others — but this field is required whatever they do with it, so a mapping supplying it must stay in place. Subscribers who move the shipping amount elsewhere should note that the LIN_AMT and TXBL_LIN_AMT mappings on the Add/Update NCR Counterpoint Item Refund Tax FROM iPaaS.com collection take the shipping amount out of the taxable total, and expect shipping to be recorded as a miscellaneous charge rather than as a line.

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. The bill-to name recorded on the refund. The formula reads the primary billing address on the iPaaS.com transaction: where that address carries a company, the company name is used; where it does not, the first and last names are joined with a space and used instead. The result is trimmed to 40 characters, because Counterpoint allows only limited space for this field. This mirrors how Counterpoint itself decides a bill-to name, and it works together with the BILL_NAM_TYP mapping below, which records which of the two the name is — the pair should be changed together or not at all.

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

This is an optional field. The bill-to first name, taken from the primary billing address on the iPaaS.com transaction and trimmed to 15 characters, because Counterpoint allows only limited space for this field. A longer first name is shortened rather than rejected, so subscribers should expect the stored name to be cut off rather than the refund to fail.

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

This is an optional field. The bill-to last name, taken from the primary billing address on the iPaaS.com transaction and trimmed to 25 characters, because Counterpoint allows only limited space for this field. A longer last name is shortened rather than rejected.

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

This is an optional field. The second line of the bill-to address, taken from the primary billing address on the iPaaS.com transaction and trimmed to 40 characters, because Counterpoint allows only limited space for this field. Where the address has no second line, the mapping supplies nothing.

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

This is an optional field. The third line of the bill-to address, taken from the primary billing address on the iPaaS.com transaction and trimmed to 40 characters, because Counterpoint allows only limited space for this field. Where the address has no third line, the mapping supplies nothing.

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

This is an optional field. The bill-to city, taken from the primary billing address on the iPaaS.com transaction and trimmed to 20 characters, because Counterpoint allows only limited space for this field.

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

This is an optional field. The bill-to postal code, taken from the primary billing address on the iPaaS.com transaction and trimmed to 15 characters, because Counterpoint allows only limited space for this field.

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

This is an optional field. The bill-to country, taken from the primary billing address on the iPaaS.com transaction and trimmed to 20 characters, because Counterpoint allows only limited space for this field. The country is written straight through in whatever form iPaaS.com carries it, so subscribers whose source system sends a full country name where Counterpoint expects a code, or the reverse, should replace this mapping with a Lookup Translation.

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

This is an optional field. Records whether the bill-to name is a person or a business. Allowed values: B for a business and P for a person; Counterpoint accepts nothing else. The formula derives the value from the same source as the BILL_NAM mapping above: where the primary billing address carries a company, the name is marked as a business; where it does not, it is marked as a person. Keeping the two derived from the same source is what stops Counterpoint being told the name is a business when a person's name was written, so subscribers replacing either mapping should replace both.

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. The ship-to name recorded on the refund, trimmed to 40 characters because Counterpoint allows only limited space for this field. Where the primary shipping address on the iPaaS.com transaction carries no company, the first and last names from that address are joined with a space and used. Where it does carry a company, the company recorded on the primary billing address is used instead of the shipping one — so subscribers whose customers ship to a business under a different name from the one they are billed under will see the billing company on the refund. Subscribers who need the shipping company recorded should change the formula to read the company from the primary shipping address.

This mapping works together with the SHIP_NAM_TYP mapping below, which records whether the name is a person or a business.

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

This is an optional field. The ship-to first name, taken from the primary shipping address on the iPaaS.com transaction and trimmed to 15 characters, because Counterpoint allows only limited space for this field. A longer first name is shortened rather than rejected.

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

This is an optional field. The ship-to last name, taken from the primary shipping address on the iPaaS.com transaction and trimmed to 25 characters, because Counterpoint allows only limited space for this field. A longer last name is shortened rather than rejected.

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

This is an optional field. The second line of the ship-to address, taken from the primary shipping address on the iPaaS.com transaction and trimmed to 40 characters, because Counterpoint allows only limited space for this field. Where the address has no second line, the mapping supplies nothing.

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

This is an optional field. The third line of the ship-to address, taken from the primary shipping address on the iPaaS.com transaction and trimmed to 40 characters, because Counterpoint allows only limited space for this field. Where the address has no third line, the mapping supplies nothing.

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

This is an optional field. The ship-to city, taken from the primary shipping address on the iPaaS.com transaction and trimmed to 20 characters, because Counterpoint allows only limited space for this field.

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

This is an optional field. The ship-to postal code, taken from the primary shipping address on the iPaaS.com transaction and trimmed to 15 characters, because Counterpoint allows only limited space for this field.

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

This is an optional field. The ship-to country, taken from the primary shipping address on the iPaaS.com transaction and trimmed to 20 characters, because Counterpoint allows only limited space for this field. As with the bill-to country above, the value is written straight through in whatever form iPaaS.com carries it, so subscribers whose source system and Counterpoint disagree on country naming should replace this mapping with a Lookup Translation.

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

This is an optional field. Records whether the ship-to name is a person or a business. Allowed values: B for a business and P for a person; Counterpoint accepts nothing else. The formula marks the name as a business where the primary shipping address on the iPaaS.com transaction carries a company, and as a person where it does not. It works together with the SHIP_NAM mapping above, so subscribers replacing either should replace both.

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

This is an optional field. The bill-to state or region, taken from the primary billing address on the iPaaS.com transaction and trimmed to 10 characters, because Counterpoint allows only limited space for this field. Subscribers whose source system carries full region names rather than short codes should be aware that a name longer than 10 characters is stored cut off, which is rarely what is wanted — a Lookup Translation that pairs each region with its code is the better fit.

The TAX_COD mapping above reads the same region to decide the refund's tax code, and compares it against a full region name rather than a code. Subscribers who change how regions are carried need to keep that formula in step.

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

This is an optional field. The ship-to state or region, taken from the primary shipping address on the iPaaS.com transaction and trimmed to 10 characters, because Counterpoint allows only limited space for this field. As with the bill-to state above, a full region name longer than 10 characters is stored cut off, and the TAX_COD mapping reads this same region when deciding the refund's tax code.

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

This is an optional field. The first line of the bill-to address, taken from the primary billing address on the iPaaS.com transaction and trimmed to 40 characters, because Counterpoint allows only limited space for this field.

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

This is an optional field. The first line of the ship-to address, taken from the primary shipping address on the iPaaS.com transaction and trimmed to 40 characters, because Counterpoint allows only limited space for this field.

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

This is an optional field. The email address recorded against the refund, taken from the iPaaS.com transaction rather than from either address, and trimmed to 50 characters because Counterpoint allows only limited space for this field. This is the same address the CUST_NO mapping above searches Counterpoint's customers on, so a refund whose customer was found by email carries the address that found them.

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

Source: SequenceNumber · Destination: SEQ_NO

This is a required field — NCR Counterpoint rejects the record without it. The position of this line within the refund, carried straight through from the iPaaS.com transaction line. Counterpoint uses it to keep the refund's lines in the order they were sent, and to tell one line from another on the same refund.

Source: "R" · Destination: LIN_TYP

This is a required field — NCR Counterpoint rejects the record without it. It is a control mapping rather than a value, and it is what makes the line a return rather than a sale. Allowed values: S for a sale, R for a return, O for an order, B for a backorder, P for a special order, L for a layaway and D for a drop-ship order; Counterpoint accepts nothing else.

This is a genuine Counterpoint constant rather than an example, so it does not need changing for a typical install. Changing it stops the line behaving as a return: the quantity is added to the sale rather than given back, and the IS_VAL_RET, RET_REAS and LINK_LIN_GUID mappings below no longer make sense against it.

Source: return await LinkLineGuidFromParentAsync(ParentId, Parent.Transaction_Parent, Qty); · Destination: LINK_LIN_GUID

This is a recommended field. Links this refund line back to the line on the original order in Counterpoint that is being returned. Counterpoint accepts the record without it, but it is what makes the refund a validated return rather than a loose credit, so it should be mapped for accurate data. Note the distinction from most mappings: Counterpoint does not reject a line that arrives without this link, but the formula below fails the transfer itself when it cannot work the link out — the failure comes from the mapping, not from Counterpoint.

The formula finds the line on the original iPaaS.com transaction that this refund line came from, reads the Counterpoint document that line was transferred to, and then looks for the released sale line that the goods actually went out on — matching only lines that were sold rather than returned or left unshipped, and only lines that were released in enough quantity to cover what is being returned. Where the original document has already been posted, the search continues into Counterpoint's posted history rather than giving up. The quantity is treated as a positive number whichever way iPaaS.com carries it, so refunds sent as negative quantities are matched correctly.

Unlike most mappings, this one raises an error and fails the transfer rather than quietly supplying nothing. It does so when the original order was never given to the integration, when the original line cannot be found on it, when the original line was never transferred to Counterpoint, when the link the integration holds for that line is not in the form Counterpoint documents and lines use, when the original document cannot be found in Counterpoint at all, or when the line exists but carries no id to link to. Every one of these means the same thing in practice: the sale being refunded is not in Counterpoint in a state that can be returned against.

Because of this, the order of transfers matters. The original order must have reached Counterpoint and been released before its refund is sent. The Mapping Filter on the parent collection is what enforces this — it holds a refund back until the original order has released lines — so subscribers should not relax that filter to work around a failure here. A refund that fails on this mapping is usually a sign that the original order has not finished its own journey into Counterpoint, not that the refund is wrong.

Source: "Y" · Destination: IS_VAL_RET

This is a recommended field — a control mapping rather than a value. Tells Counterpoint the line is a validated return: one checked against the original sale rather than accepted on its own. Counterpoint accepts the record without it and records N instead, which marks the return as unvalidated, so it should be mapped for accurate data. Allowed values: Y and N.

This collection only ever transfers validated returns — the parent collection's Mapping Filter admits nothing else — so this is a genuine constant rather than an example and does not need changing for a typical install. It works together with the LINK_LIN_GUID mapping above, which supplies the original sale line the return is validated against; flagging a line as validated without that link leaves Counterpoint with nothing to validate it against.

Source: "WEBSITE" · Destination: RET_REAS

This is an optional field as far as Counterpoint's own record is concerned, but where it is mapped the value must be a reason code configured in your own Counterpoint installation; the integration supplies a value on every refund line so that returns arriving from iPaaS.com can be told apart from returns taken at the counter. The reason code recorded against the return.

Counterpoint accepts the refund line without a reason code, and it does not check the value against the reason codes configured in your installation as the line 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 return 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.

Every line of every refund carries the same reason, so subscribers who want to record why each item came back — rather than simply where it came back from — should replace the Static with a formula or a Lookup Translation driven by the reason held on the iPaaS.com transaction line.

Source: "N" · Destination: IS_DISCNTBL

This is a recommended field. Marks the refund line as not discountable, which stops Counterpoint applying its own discount rules to it. Counterpoint accepts the record without it and records Y instead — the opposite of what this mapping supplies, leaving the line open to Counterpoint's discount rules — so it should be mapped for accurate data. Allowed values: Y and N.

The amount being given back was already settled when the goods were sold, so letting Counterpoint discount it again would change the refund to something other than what the customer is owed. This is a genuine Counterpoint constant rather than an example and does not need changing for a typical install.

Source: ItemNumberFromSku(Sku) · Destination: ITEM_NO

This is a required field — NCR Counterpoint rejects the record without it. The Counterpoint item being returned, and the value must be an existing Counterpoint item in your own installation. The formula reads the SKU on the iPaaS.com transaction line and takes the item number out of it: iPaaS.com carries grid dimensions and units on the SKU alongside the item number, and this strips them off so that only the item number reaches Counterpoint. A SKU that carries neither is used as-is. The dimensions that were stripped are picked up separately by the DIM_1_UPR, DIM_2_UPR and DIM_3_UPR mappings below.

Counterpoint requires an item number to be present, but it does not check the value against the items held in your installation as the refund line transfers: an item 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 whose SKUs in iPaaS.com are not the item numbers Counterpoint knows the goods by should replace this mapping, since the item number is what Counterpoint puts the returned stock back against, and should confirm the items their refunds reference exist in Counterpoint before enabling this collection.

Source: Description · Destination: DESCR

This is a required field — NCR Counterpoint rejects the record without it. The description of the item being returned, carried straight through from the iPaaS.com transaction line. This is the description as it stood on the original sale rather than as it stands on the item in Counterpoint today, which is what allows the refund to show the customer what they actually bought.

Source: "Y" · Destination: HAS_TAX_OVRD

This is a required field — NCR Counterpoint rejects the record without it, raising Tax override(HAS_TAX_OVRD) is a required field. Unlike most of the yes/no flags on this collection, this one has no default behind it, so it must be supplied on every line. Tells Counterpoint the line's tax has been overridden, so that Counterpoint does not work the tax out for itself. Allowed values: Y and N.

The tax being given back is the tax the customer actually paid, and it reaches Counterpoint through the TAX_AMT_ALLOC mapping below. Letting Counterpoint recalculate it against today's tax rules would risk refunding a different amount from the one that was charged. This is a genuine Counterpoint constant rather than an example and does not need changing for a typical install; it is the line-level counterpart of the SAL_HAS_TAX_OVRD mapping on the parent collection.

Source: EstimatedTaxAmount · Destination: TAX_AMT_ALLOC

This is a recommended field. The tax being given back on this line, held to two decimal places, carried straight through from the iPaaS.com transaction line. Counterpoint accepts the record without it and records 0 instead — which would give the customer their tax back nowhere — so it should be mapped for accurate data. Because the HAS_TAX_OVRD mapping above tells Counterpoint not to calculate tax itself, this value is the tax Counterpoint records — a line whose iPaaS.com tax amount is wrong refunds the wrong tax rather than being corrected.

Source: Qty · Destination: QTY_SOLD

This is a recommended field. The quantity being returned, carried straight through from the iPaaS.com transaction line. Counterpoint accepts the record without it and records 1 instead, so a line that failed to supply a quantity would refund a single unit whatever was actually sent back — it should be mapped for accurate data. On a return line this is the quantity coming back rather than going out, and it is also the quantity the LINK_LIN_GUID mapping above checks the original sale against — a return for more than was released against the original line cannot be linked, and the transfer fails.

Source: "0" · Destination: QTY_SHIPPED

This is a recommended field. The quantity shipped against the line. Counterpoint accepts the record without it and records 0 instead, so it should be mapped for accurate data. Nothing is shipped out on a return, so zero is the correct value, and Counterpoint maintains the figure from there. This is a genuine starting value rather than an example and does not need changing for a typical install.

Source: "0" · Destination: QTY_ENTD

This is a recommended field. The quantity entered against the line, as distinct from the quantity being returned, which the QTY_SOLD mapping above supplies. Counterpoint accepts the record without it and records 0 instead, so it should be mapped for accurate data. Zero is the correct value for a refund arriving from iPaaS.com, since nothing is being entered for future release. This is a genuine starting value rather than an example and does not need changing for a typical install.

Source: OriginalUnitPrice · Destination: CALC_PRC

This is an optional field. The price Counterpoint records as the calculated one for the line, held to two decimal places, taken from the price the item originally carried on the iPaaS.com transaction line before any discount was applied. Recording it alongside the PRC mapping below is what lets Counterpoint show the difference between what the item normally sells for and what the customer is actually being given back.

Source: UnitPrice · Destination: PRC

This is an optional field. The unit price being refunded, held to two decimal places, taken from the price the customer actually paid on the iPaaS.com transaction line. Because the HAS_PRC_OVRD mapping below tells Counterpoint not to price the line itself, this is the price Counterpoint records rather than a starting point it works from.

Source: "Y" · Destination: HAS_PRC_OVRD

This is a recommended field — a control mapping rather than a value. Tells Counterpoint the line's price has been overridden, so that Counterpoint does not price the line against its own price rules. Counterpoint accepts the record without it and records N instead — the opposite of what this mapping supplies, which lets Counterpoint reprice the line — so it should be mapped for accurate data. Allowed values: Y and N.

The customer is owed what they paid, which may differ from what the item sells for today, so the price on the refund has to be the one carried over rather than one recalculated. This is a genuine Counterpoint constant rather than an example and does not need changing for a typical install. It works together with the PRC_OVRD_REAS mapping below, which Counterpoint expects whenever a price has been overridden.

Source: "WEBSITE" · Destination: PRC_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. The reason code recorded against the price override. Counterpoint accepts the record without it, but the HAS_PRC_OVRD mapping above tells Counterpoint the line's price has been overridden, and a reason belongs with an override — so it should be mapped for accurate data.

Counterpoint does not check the value against the reason codes configured in your installation as the line 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 price-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.

Source: ExtendedPrice · Destination: EXT_PRC

This is a required field — NCR Counterpoint rejects the record without it, raising Ext prc(EXT_PRC) is a required field. The extended price of the line — the total being refunded for this item before tax — held to two decimal places and carried straight through from the iPaaS.com transaction line. Counterpoint stores it as sent rather than working it out from the quantity and price, so subscribers replacing the PRC or QTY_SOLD mappings above should make sure this value still agrees with them; a line whose extended price does not match its quantity times its price refunds the extended price.

Source: GridDimFromSku(Sku, 1) · Destination: DIM_1_UPR

This is an optional field. The first grid dimension of the item being returned — colour, size or whatever the first dimension holds in your own Counterpoint installation. The formula reads the SKU on the iPaaS.com transaction line and takes the first dimension out of it, working alongside the ITEM_NO mapping above, which takes the item number from the same SKU.

Where the SKU carries no grid dimensions at all, or carries fewer than this position needs, the formula supplies a wildcard rather than nothing — which is how Counterpoint records a line against an item that is not gridded. Subscribers whose iPaaS.com SKUs do not carry grid dimensions in the form iPaaS.com uses should replace this mapping, since a gridded item returned against the wrong dimension puts the stock back in the wrong place.

Source: GridDimFromSku(Sku, 2) · Destination: DIM_2_UPR

This is an optional field. The second grid dimension of the item being returned, read from the SKU on the iPaaS.com transaction line in the same way as the DIM_1_UPR mapping above. Where the SKU carries no second dimension, the formula supplies a wildcard rather than nothing.

Source: GridDimFromSku(Sku, 3) · Destination: DIM_3_UPR

This is an optional field. The third grid dimension of the item being returned, read from the SKU on the iPaaS.com transaction line in the same way as the DIM_1_UPR mapping above. Where the SKU carries no third dimension, the formula supplies a wildcard rather than nothing.

Source: Custom field:SellingUnit` · Destination: QTY_UNIT

This is an optional field. The unit the item is being returned in — the each, the six-pack, the case. The value comes from a custom field named SellingUnit on the iPaaS.com transaction line rather than from a standard field, so it is only populated where the system that created the transaction was set up to record the selling unit there.

Where that custom field carries nothing, the mapping supplies nothing and Counterpoint records the return against the item's stocking unit. For subscribers who sell in a single unit that is the right answer. Subscribers who sell the same item in more than one unit should confirm the selling unit is reaching iPaaS.com before enabling this collection: a case returned as an each puts the wrong quantity of stock back.

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

Source: "C" · Destination: PMT_LIN_TYP

This is a recommended field — a control mapping rather than a value, and it is what makes the payment money going back to the customer rather than money coming in. Counterpoint accepts the record without it and records T instead, which reads the payment as a tender — money coming in rather than going back — so it should be mapped for accurate data. Allowed values: T for a tender, C for change or a refund, and J for a deposit justification; Counterpoint accepts nothing else.

This is a genuine Counterpoint constant rather than an example, so it does not need changing for a typical install. Changing it reverses the direction of the money: a refund payment recorded as a tender is read by Counterpoint as the customer paying, not being paid.

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. The Counterpoint pay code the refund is given back through — it is what tells Counterpoint where the refunded money is going. Counterpoint accepts the record without it, so a payment method with no matching row in the translation transfers with the pay code empty rather than failing; it should be mapped for accurate data. The translation takes the payment method recorded on the iPaaS.com transaction and pairs it with a pay code Counterpoint knows.

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 these pairs:

The last two rows of the shipped pairs are conditions rather than plain values: they look at the gift card behind the payment and sort it into a gift card or a store credit accordingly.

Two things need attention before the first transfer. The pay codes on the right of the table are example values rather than Counterpoint defaults — replace them with pay codes configured in your own Counterpoint installation. And the methods on the left are the ones the shipped pairs anticipate; a payment method your source system uses that is not listed here has nothing to pair with, so subscribers should check their own methods against this list and add the ones that are missing.

Placeholder value — replace during implementation: the pay codes this translation supplies are example values, not Counterpoint defaults. Replace them with pay codes from your own Counterpoint installation before enabling this collection. Note that most methods are paired to a single cash pay code, which records every card refund as cash — subscribers who want card refunds recorded against a card pay code need to repair those rows.

This translation is shared with the payment collections on the other transaction families that write to Counterpoint — Add NCR Counterpoint Order Payment FROM iPaaS.com, Add NCR Counterpoint Sale Ticket Payment FROM iPaaS.com, Add NCR Counterpoint Deposit Ticket Payment FROM iPaaS.com and Add/Update NCR Counterpoint Deposit Refund Payment FROM iPaaS.com. Editing it here changes it for all of them, which is usually what subscribers want, but it does mean a change made for refunds also lands on sales.

Source: Amount · Destination: AMT

This is a recommended field. The amount being given back through this payment, held to two decimal places, carried straight through from the iPaaS.com transaction payment. Counterpoint accepts the record without it and records 0 instead — a payment that gives nothing back — so it should be mapped for accurate data. Where a refund is given back across more than one payment, each one is transferred by this collection with its own amount, and the amounts should add up to the refund's total — Counterpoint records what it is sent rather than working the figure out for itself.

The parent collection holds back any refund whose first payment was declined, so a declined payment does not reach this mapping.

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

Mapping Filter

Filter Description.

The filter admits only the tax held on the refund itself, not the tax held on each of its lines. The whole of the refund's tax is therefore recorded as a single tax entry against a single authority. A refund whose tax needs splitting across more than one authority is not something this collection can express, and subscribers in that position need a mapping collection per authority rather than a change to this filter.

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

This is a required field — NCR Counterpoint rejects the record without it, raising Authority(AUTH_COD) is a required field. The tax authority the refunded tax is recorded against, and the value must be a tax authority configured in your own Counterpoint installation. Counterpoint requires an authority to be present, but it does not check the value against the authorities configured in your installation as the tax record transfers: an authority 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 authority exists in Counterpoint before enabling this collection.

The formula is a template that sorts each refund into one of three tax situations: a refund carrying tax whose region is the named home state, a refund carrying tax whose region is anywhere else, and a refund carrying no tax. The region is read from the refund's primary shipping address, falling back to the primary billing address where the transaction has no shipping address. Refunds carry negative tax amounts, which is why the test is for tax below zero rather than above it.

As shipped, all three branches supply the same authority, so the formula currently produces one authority for every refund regardless of region. The branching is there so that subscribers can give each situation its own authority; it does nothing until they do.

Placeholder value — replace during implementation: the home-state name and the authority in this formula are example values, not Counterpoint defaults. Replace them with the region and the tax authorities configured in your own Counterpoint installation before enabling this collection. The RUL_COD mapping below and the TAX_COD mapping on the parent collection carry the same example region and must be changed to agree with whatever is set here.

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

This is a required field — NCR Counterpoint rejects the record without it, raising Rule(RUL_COD) is a required field. The tax rule within that authority the refunded tax is recorded against, and the value must be a tax authority rule configured in your own Counterpoint installation. It belongs with the authority the AUTH_COD mapping above supplies. As with the authority, Counterpoint requires a rule to be present but does not check the value against the rules configured in your installation as the tax record transfers: a rule 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 authority rule exists in Counterpoint, and belongs to the authority above, before enabling this collection.

The formula follows the same three-way template as the authority above, reading the same region from the same addresses and testing the same negative tax amount. As shipped, all three branches supply the same rule, so the formula currently produces one rule for every refund regardless of region.

Placeholder value — replace during implementation: the home-state name and the rule in this formula are example values, not Counterpoint defaults. Replace them with the region and the tax rules configured in your own Counterpoint installation before enabling this collection. A rule must belong to the authority supplied above, so the two mappings should be changed together.

Source: "S" · Destination: TAX_DOC_PART

This is a recommended field — a control mapping rather than a value, and it tells Counterpoint which part of the document the tax record belongs to. Counterpoint accepts the record without it and records S instead, which is the same value this mapping supplies, so it should be mapped for accurate data. Allowed values: S for the sale part, O for the order part, L for the layaway part and F for foodstamps; Counterpoint accepts nothing else.

Refunds are transferred as ticket documents, so the tax belongs to the sale part. This is a genuine Counterpoint constant rather than an example and does not need changing for a typical install.

Source: Parent.TaxAmount · Destination: NORM_TAX_AMT

This is a recommended field. The tax that would normally have applied, held to two decimal places, read from the refund's total tax amount. Counterpoint accepts the record without it, but it reads this alongside the TAX_AMT mapping below to tell an overridden tax from an ordinary one, so it should be mapped for accurate data.

This mapping and TAX_AMT below both read the same total, so as shipped Counterpoint is told the tax given back is exactly the tax that would normally have applied. The value is negative, because a refund gives tax back rather than takes it.

Source: Parent.TaxAmount · Destination: TAX_AMT

This is a recommended field. The tax being given back, held to two decimal places, read from the refund's total tax amount rather than worked out from the lines. Counterpoint accepts the record without it, but this is the mapping that carries the refunded tax, so it should be mapped for accurate data.

The whole of the refund's tax is recorded as a single tax entry against the single authority the AUTH_COD mapping above supplies. This is what the collection is built around, and it is why the Mapping Filter admits only the transaction's own tax rather than the tax held on each line: a refund whose tax needs splitting across more than one authority is not something this collection can express, and subscribers in that position need a mapping collection per authority rather than a change to this formula.

Because the SAL_HAS_TAX_OVRD mapping on the parent collection tells Counterpoint the refund's tax is overridden, this value is the tax Counterpoint records rather than a figure it checks. A refund whose iPaaS.com tax amount is wrong gives back the wrong tax rather than being corrected.

Source: Parent.TotalQty · Destination: TXBL_QTY

This is an optional field. The quantity the refunded tax was worked out against, read from the refund's total quantity across all its lines. Because the tax is recorded as a single entry for the whole refund rather than line by line, the quantity that belongs with it is the refund's total rather than any one line's.

Subscribers refunding items that are not all taxable should be aware that this is the total quantity rather than the taxable quantity: the two are the same only where every line on the refund carries tax.

Source: (Parent.Subtotal-Parent.ShippingAmount) · Destination: LIN_AMT

This is an optional field. The line amount the refunded tax was worked out against, held to two decimal places. The formula takes the refund's subtotal and subtracts the shipping, because shipping is recorded on the refund as a miscellaneous charge through the SAL_MISC_AMT_1 mapping on the parent collection rather than as a line — leaving it in would count it twice.

Subscribers who move the shipping amount out of the miscellaneous charge field on the parent collection need to revisit this formula and the TXBL_LIN_AMT mapping below, since both assume shipping is held there.

Source: (Parent.Subtotal-Parent.ShippingAmount) · Destination: TXBL_LIN_AMT

This is an optional field. The taxable portion of the line amount, held to two decimal places, worked out the same way as the LIN_AMT mapping above: the refund's subtotal less the shipping.

As shipped, the taxable amount and the line amount are the same figure, which tells Counterpoint the whole of the refund was taxable. That is correct where every line on the refund carries tax. Subscribers who refund a mix of taxable and non-taxable items, or who charge tax on shipping, should replace this formula with one that supplies only the taxable portion — otherwise Counterpoint's tax reporting shows a larger taxable base than was actually taxed.

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.

At the time this documentation was written:

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