This mapping collection writes completed sales from iPaaS.com into NCR Counterpoint as sale tickets. Each transferred transaction becomes a ticket carrying its own ticket number, the store, station, drawer and user it is attributed to, the billing and shipping names and addresses, the ticket's subtotal, tax, shipping charge and total, and the tax override that tells Counterpoint to keep the tax figures as they arrive rather than working out its own.

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. The Order and Sale Ticket paths from iPaaS.com to Counterpoint are alternatives, not companions. They write the same sales to Counterpoint in two different shapes, and running both double-writes every sale. Before enabling this collection, subscribers or their MiSP must decide which of the two paths is the source of truth for sales in Counterpoint, and must review the mapping filters and the Add and Update settings on every collection named below rather than enabling this one in isolation.

Each of these transfers as part of the ticket rather than on its own:

Mapping Filter

Filter Description.

The leading 1==0 term is what disables the collection, as described under Mapping Collection Status above. The remaining terms are the ones that do the real work once that term is removed. They exclude:

Subscribers who relax any of these terms should expect the excluded transactions to reach Counterpoint as ordinary sale tickets, which is what the terms exist to prevent.

Source: "BC" + TransactionNumber · Destination: TKT_NO

This is a required field — NCR Counterpoint rejects the record without it. The ticket number NCR Counterpoint identifies the sale by. The formula takes the iPaaS.com transaction number and puts a two-character prefix in front of it, so that tickets arriving from iPaaS.com are distinguishable from tickets entered at the point of sale.

Placeholder value — replace during implementation: "BC" is an example prefix, not a Counterpoint default — it was chosen for a BigCommerce pairing and is carried by every ticket this collection creates. Replace it with a prefix that is meaningful for your own installation before enabling this collection. Keep any replacement to two characters; the surrounding template assumes that length.

Source: "T" · Destination: DOC_TYP

This is a recommended field — it tells NCR Counterpoint what kind of document to create. Counterpoint accepts the record without it and records T instead, so it should be mapped for accurate data. The static value marks the document as a ticket, which is what this collection exists to create, and it matches the value Counterpoint would have supplied on its own. Counterpoint also recognizes values for holds, voided tickets, quotes, orders, layaways, order-entry orders, order-entry invoices, and voided order-entry invoices. This is a genuine Counterpoint constant rather than an example, so it does not need changing for a typical install. Changing it changes what kind of document every transfer creates, which is a different collection's job rather than a configuration choice.

Source: "O" · Destination: DOC_STAT

This is a recommended field — it sets the state the ticket is created in. Counterpoint accepts the record without it and records O instead, so it should be mapped for accurate data. The static value creates every ticket as open, which matches the value Counterpoint would have supplied on its own. Counterpoint also recognizes values meaning completed and cancelled. This is a genuine Counterpoint constant rather than an example, so it does not need changing for a typical install.

Source: "MAIN" · Destination: STR_ID

This is a required field — NCR Counterpoint rejects the record without it. It is the store the ticket is created in, and it must be a store configured in your own Counterpoint installation.

Only presence is checked during the transfer, not the value. A store id your installation does not have is accepted and stored on the ticket rather than being reported as a transfer error, and it then fails later — when the ticket is posted or used by another Counterpoint function — rather than at the point of transfer. 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 tickets should be created in, taken from your own Counterpoint installation, before enabling this collection — a store id that installation does not have is stored rather than refused, and surfaces later rather than as a transfer error. Because this is a fixed value, tickets from every source are attributed to whichever single store is set here. Subscribers running multiple stores should consider whether a fixed value is correct for their reporting, and replace it with a formula if not.

Source: "MAIN" · Destination: STK_LOC_ID

This is a recommended field. It is the stocking location the ticket draws its inventory from, and it is what decides which location is decremented when the ticket is processed. Counterpoint accepts the record without it, but a ticket that arrives with no stocking location does not identify the inventory it came out of, so subscribers should keep it mapped.

Whatever value is supplied must be a Counterpoint location that exists in your own installation. Nothing checks that during the transfer. A location id your installation does not have is accepted and stored on the ticket rather than being reported as a transfer error, and it then fails later — when the ticket is posted, or when Counterpoint comes to relieve stock against the location — rather than at the point of transfer. Subscribers or their MiSP should confirm the location exists in Counterpoint before enabling this collection.

Placeholder value — replace during implementation: "MAIN" is an example stocking location id, not a Counterpoint default. Replace it with the id of the location the tickets should draw from, taken from your own Counterpoint installation, before enabling this collection — a location id that installation does not have is stored rather than refused, and surfaces later rather than as a transfer error. This value is set independently of STR_ID above, so subscribers whose store and stocking location differ should set each one to the value that is correct for it rather than assuming they match.

Source: "1" · Destination: STA_ID

This is a required field — NCR Counterpoint rejects the record without it. It is the station the ticket is recorded against, and it must be a station configured in your own Counterpoint installation.

As with STR_ID above, only presence is checked during the transfer, not the value. A station id your installation does not have is accepted and stored on the ticket rather than being reported as a transfer error, and it then fails later — when the ticket is posted or used by another Counterpoint function — rather than at the point of transfer. 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. A single-character value here is an id rather than a flag, so it needs the same attention as any other identifier; subscribers who intend tickets from iPaaS.com to be identifiable in Counterpoint reporting will usually want a station set aside for them rather than one already used by a till.

Source: "1" · Destination: DRW_ID

This is a recommended field. It is the drawer the ticket is recorded against. Counterpoint accepts the record without it, so it should be mapped for accurate data rather than to prevent a failure.

Whatever value is supplied must be a drawer configured in your own Counterpoint installation. Nothing checks that during the transfer. A drawer id your installation does not have is accepted and stored on the ticket rather than being reported as a transfer error, and it then fails later — when the ticket is posted or used by another Counterpoint function — rather than at the point of transfer. 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. As with STA_ID above, the single-character value is an id and not a flag, and it is set independently of the station; a drawer id that installation does not have is stored rather than refused.

Source: "Z" · Destination: USR_ID

This is a recommended field. It is the point of sale user recorded as having entered the ticket. Counterpoint accepts the record without it, so it should be mapped for accurate attribution rather than to prevent a failure.

Whatever value is supplied must be a Counterpoint user that exists in your own installation. Nothing checks that during the transfer. A user id your installation does not have is accepted and stored on the ticket rather than being reported as a transfer error, and it then fails later — when the ticket is posted, or when another Counterpoint function reads it — rather than at the point of transfer. 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 — a user id that installation does not have is stored rather than refused, and surfaces later rather than as a transfer error. Every ticket this collection creates is attributed to whichever single user is set here, so subscribers usually want a user that represents the integration rather than a person, which also keeps online tickets separable from staff-entered ones in Counterpoint reporting.

Source: "0" · Destination: TIMES_PRTD

This is a recommended field. It records how many times the ticket has been printed, and zero is the standard starting value for a ticket that has just been created. Counterpoint accepts the record without it and records 0 instead, which is the same value this mapping supplies, so the mapping restates what Counterpoint would have done on its own. This is a genuine starting value rather than an example, so it does not need changing for a typical install.

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

This is an optional field. Links the ticket to a Counterpoint customer by searching for one whose primary email address matches the email address on the iPaaS.com transaction. The match is exact, and it looks at the primary email address only — a customer whose address is held in a secondary email field is not found. Where several customers share an address, one flagged as an ecommerce customer is preferred; if none is, the first customer Counterpoint returns is used, and which one that is is not something the integration decides.

Where a customer number is supplied, it must be an existing Counterpoint customer. Nothing checks that during the transfer. A customer number your installation does not have is accepted and stored on the ticket rather than being reported as a transfer error, and it then fails later — when the ticket is posted or used by another Counterpoint function — rather than at the point of transfer.

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.

This mapping does not create or transfer the customer, so subscribers who want tickets linked to real customer records should ensure customers are already transferring to Counterpoint before enabling this collection.

Lookups are held briefly after they are performed, so a customer created moments before a ticket arrives may not be visible to the first attempt.

Source: "A" · Destination: SAL_HAS_TAX_OVRD

This is a recommended field — it is what stops NCR Counterpoint from calculating its own tax on the ticket. Counterpoint accepts the record without it and records ! instead, so it should be mapped for accurate data; a ticket that arrives without it does not carry the override, and the tax figures sent from iPaaS.com are not the ones the ticket keeps. The static value tells Counterpoint that the ticket has a tax override and that the override is by amount rather than by percentage, so the tax figures supplied by Add NCR Counterpoint Sale Ticket Tax FROM iPaaS.com are used as they arrive. Counterpoint also recognizes values meaning no override and tax exempt. This is a genuine Counterpoint constant rather than an example.

This mapping is the reason TAX_OVRD_REAS and TAX_EXEMPT_NO below are populated: once a ticket carries a tax override, a reason and an exemption number are what explain it, even though Counterpoint accepts the ticket without either. Subscribers who want Counterpoint to calculate tax itself would need to revisit all four mappings together, not this one alone.

Note that this is a different field from the line-level HAS_TAX_OVRD in Add NCR Counterpoint Sale Ticket Line FROM iPaaS.com, and the two do not take the same values.

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 for accurate tax reporting. It is the tax code the ticket is created against, and Counterpoint accepts the record without it.

Whatever value is supplied must be a tax code configured in your own Counterpoint installation. Nothing checks that during the transfer. A tax code your installation does not have is accepted by the transfer and stored on the ticket rather than being reported as a transfer error, and it then fails later — when the ticket is posted, or when another Counterpoint function uses it — rather than at the point of transfer. Subscribers or their MiSP should confirm the tax code exists in Counterpoint before enabling this collection.

The formula is shaped to tell three situations apart: a taxed ticket inside the home region, a taxed ticket outside it, and an untaxed ticket. It decides which by taking the region from the primary shipping address, falling back to the primary billing address where there is no shipping region, and comparing it against a named region.

As shipped, all three branches return the same code, so the formula always produces MEMTN whatever the region and whatever the tax amount. Subscribers who need it can give each of the three situations a different code; until they do, it has no effect on the result.

Placeholder value — replace during implementation: "MEMTN" is an example tax code and "Tennessee" an example region, not Counterpoint defaults. Replace them with a tax code and region from your own Counterpoint installation before enabling this collection, giving each of the three branches the code that is correct for it.

Source: "WEBSITE" · Destination: TAX_OVRD_REAS

This is a recommended field. It records why the tax on the ticket was overridden, and the template populates it because the ticket carries a tax override set by SAL_HAS_TAX_OVRD above. Counterpoint accepts the record without it, so it should be mapped so that overridden tax is explained in your Counterpoint reporting rather than to prevent a failure.

Whatever value is supplied must be a reason code configured in your own Counterpoint installation. Nothing checks that during the transfer. A reason code your installation does not have is accepted and stored on the ticket rather than being reported as a transfer error, and it then fails later — when the ticket is posted or used by another Counterpoint function — rather than at the point of transfer. This is unlike TAX_EXEMPT_NO below, which is free text and carries no such consequence. 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 — a reason code that installation does not have is stored rather than refused, and surfaces later rather than as a transfer error.

Source: "WEBSITE" · Destination: TAX_EXEMPT_NO

This is a recommended field. Where the ticket's tax is overridden and no tax is charged, a tax exemption number is what records why, and the template supplies one on every ticket rather than only on untaxed ones. Counterpoint accepts the record without it, and it does not validate the format or the contents of the field either, so any value is accepted.

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 the field is free text rather than a lookup, a wrong value here is not rejected — it is simply recorded on every ticket, which makes it worth setting deliberately rather than leaving as the example.

Source: Subtotal · Destination: SAL_SUB_TOT

This is a required field — NCR Counterpoint rejects the record without it, with Sales(SAL_SUB_TOT) is a required field. The ticket's subtotal before tax and shipping. A value has to arrive, but it is not the last word on what the ticket is worth: the subtotal is recalculated from the ticket's lines once the ticket is created. Subscribers should still map it accurately rather than supplying a placeholder to satisfy the requirement — a mismatch between what arrives here and what the lines recalculate to is a useful signal that the lines did not transfer as expected.

Source: DiscountAmount · Destination: SAL_TOT_HDR_DISC

This is a recommended field. The discount applied to the ticket as a whole, as opposed to discounts applied to individual lines. Tickets with no header-level discount transfer with it empty.

Source: TaxAmount · Destination: SAL_TAX_AMT

This is a required field — NCR Counterpoint rejects the record without it, with Tax amount(SAL_TAX_AMT) is a required field. The total tax on the ticket, taken from iPaaS.com rather than calculated by Counterpoint — SAL_HAS_TAX_OVRD above is what stops Counterpoint from calculating its own. The same amount is also written to the ticket's tax record by Add NCR Counterpoint Sale Ticket Tax FROM iPaaS.com, so subscribers changing how tax reaches Counterpoint should keep the two consistent with each other.

Source: ShippingAmount · Destination: SAL_MISC_AMT_1

This is a required field — NCR Counterpoint rejects the record without it, with Misc charge 1(SAL_MISC_AMT_1) is a required field. It carries the ticket's shipping charge into the first of Counterpoint's miscellaneous amount fields. There is nothing shipping-specific about the field itself; it is a general-purpose slot that this template uses for shipping. Subscribers already using it for something else can carry the shipping charge in one of the other miscellaneous amount fields instead, but this field still has to receive a value of its own, so it needs its own mapping rather than simply having this one moved off it.

Source: Total · Destination: SAL_TOT

This is a required field — NCR Counterpoint rejects the record without it, with Total(SAL_TOT) is a required field. The ticket total. As with SAL_SUB_TOT above, a value has to arrive, but the total is recalculated once the ticket is created, so what is supplied here does not decide what the ticket ends up worth.

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

This is a recommended field. The shipping method, taken from the primary shipping address on the iPaaS.com transaction. Where a transaction has no primary shipping address the formula supplies nothing.

The value passes through as it arrives, and whatever arrives must be a ship-via code configured in your own Counterpoint installation. Nothing checks that during the transfer. A shipping method the installation does not have as a ship-via code is accepted and stored on the ticket rather than being reported as a transfer error, and it then fails later — when the ticket is posted or used by another Counterpoint function — rather than at the point of transfer, which makes an unmatched shipping method easy to miss because the tickets carrying it transfer successfully.

The shipping method names coming from iPaaS.com therefore need to correspond to the ship-via codes configured in your own Counterpoint installation. Subscribers whose shipping method names differ from their Counterpoint codes should replace this mapping with a Lookup Translation, which is what that mapping type exists for, rather than trying to make the two systems agree by renaming things in either one.

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

This is a recommended field. Tells Counterpoint whether the billing name belongs to a person or a business. The formula decides from the primary billing address: an address with no company is treated as a person, and an address with one is treated as a business. This mirrors how Counterpoint itself treats the two, and it works as a pair with BILL_NAM below, which selects the matching name. Subscribers replacing either mapping should keep both deciding from the same source, so that the name type and the name cannot disagree.

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 a recommended field. The billing name. Where the primary billing address has a company, the company is used; otherwise the first and last names are joined with a space. The result is trimmed to 40 characters to fit the space Counterpoint allows, so longer names are shortened rather than rejected.

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

This is a recommended field. The first name from the primary billing address, trimmed to 15 characters to fit the space Counterpoint allows.

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

This is a recommended field. The last name from the primary billing address, trimmed to 25 characters to fit the space Counterpoint allows.

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

This is a recommended field. The first line of the primary billing address, trimmed to 40 characters to fit the space Counterpoint allows. Where the transaction has no primary billing address, this and every other billing mapping in this collection supply nothing, and the ticket is created without billing details.

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

This is an optional field. The second line of the primary billing address, trimmed to 40 characters. Addresses with only one line transfer with it empty.

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

This is an optional field. The third line of the primary billing address, trimmed to 40 characters. Addresses with fewer than three lines transfer with it empty.

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

This is a recommended field. The city from the primary billing address, trimmed to 20 characters to fit the space Counterpoint allows.

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

This is a recommended field. The state or region from the primary billing address, trimmed to 10 characters to fit the space Counterpoint allows. Subscribers whose regions arrive as full names rather than abbreviations should check that 10 characters is enough for the regions they trade in, since a longer name is shortened rather than rejected. This field is also the fallback the TAX_COD formula above uses when a transaction has no shipping region.

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

This is a recommended field. The postal code from the primary billing address, trimmed to 15 characters to fit the space Counterpoint allows.

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

This is a recommended field. The country from the primary billing address, trimmed to 20 characters to fit the space Counterpoint allows. Unlike some other collections in this integration, this mapping supplies no fallback country, so an address with no country transfers with it empty.

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

This is a recommended field. The email address from the iPaaS.com transaction, trimmed to 50 characters to fit the space Counterpoint allows. This is taken from the transaction itself rather than from the billing address, and it is the same address CUST_NO above uses to find the Counterpoint customer.

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

This is a recommended field. Tells Counterpoint whether the shipping name belongs to a person or a business, decided from the primary shipping address: an address with no company is treated as a person, and an address with one is treated as a business. It works as a pair with SHIP_NAM below.

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 a recommended field. The shipping name, trimmed to 40 characters to fit the space Counterpoint allows. Where the primary shipping address has no company, the first and last names from the shipping address are joined with a space.

Where the shipping address does have a company, the formula supplies the company from the billing address rather than the shipping address. For transactions where the two companies are the same this makes no difference, but where they differ the ticket is shipped under the billing company's name. Subscribers who ship to companies that differ from the company being billed should replace the mapping so that it takes the company from the shipping address, and should check any tickets already created this way.

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

This is a recommended field. The first name from the primary shipping address, trimmed to 15 characters to fit the space Counterpoint allows.

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

This is a recommended field. The last name from the primary shipping address, trimmed to 25 characters to fit the space Counterpoint allows.

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

This is a recommended field. The first line of the primary shipping address, trimmed to 40 characters to fit the space Counterpoint allows. Where the transaction has no primary shipping address — which is normal for an order that is collected rather than delivered — this and every other shipping mapping in this collection supply nothing, and the ticket is created without shipping details.

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

This is an optional field. The second line of the primary shipping address, trimmed to 40 characters. Addresses with only one line transfer with it empty.

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

This is an optional field. The third line of the primary shipping address, trimmed to 40 characters. Addresses with fewer than three lines transfer with it empty.

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

This is a recommended field. The city from the primary shipping address, trimmed to 20 characters to fit the space Counterpoint allows.

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

This is a recommended field. The state or region from the primary shipping address, trimmed to 10 characters to fit the space Counterpoint allows. This is the region the TAX_COD formula above reads first when deciding which tax code the ticket gets, so subscribers changing how regions arrive from iPaaS.com should check that formula at the same time.

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

This is a recommended field. The postal code from the primary shipping address, trimmed to 15 characters to fit the space Counterpoint allows.

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

This is a recommended field. The country from the primary shipping address, trimmed to 20 characters to fit the space Counterpoint allows. As with BILL_CNTRY above, no fallback country is supplied, so an address with no country transfers with it empty.

Parent: Add NCR Counterpoint Sale Ticket FROM iPaaS.com.

Source: Type · Destination: NOTE_ID

This is a required field — NCR Counterpoint rejects the record without it, with Note id(NOTE_ID) is a required field. It is what identifies the note on the ticket. The value comes from the note's type in iPaaS.com, so the note's kind is what names it in Counterpoint rather than a code of its own.

The value passes through as it arrives. Subscribers whose Counterpoint installation expects note ids drawn from a configured list should confirm that the note types coming from iPaaS.com correspond to them, and replace this mapping with a Lookup Translation if they do not.

Source: SequenceNumber · Destination: NOTE_SEQ_NO

This is a required field — NCR Counterpoint rejects the record without it. It is what keeps a ticket's notes in order and distinguishes one from another where a ticket carries several. The sequence number from the iPaaS.com note is carried through as it arrives.

Source: LocalDateTimeFromDateTimeOffset(NoteCreatedDateTime) · Destination: NOTE_DAT

This is a recommended field. The date and time the note was written. iPaaS.com records this with a time zone offset attached, and Counterpoint stores a plain local date and time, so the formula converts between the two rather than passing the value straight through.

Subscribers should validate the resulting timestamps in a staging environment before relying on them in production — particularly those operating across time zones, or whose Counterpoint server does not run in the same zone as the business it serves, since the conversion is what decides which local time a note is recorded at.

Source: Text · Destination: NOTE_TXT

This is a recommended field. It is the note itself, and Counterpoint accepts the record without it, so a note that arrives with no text is created empty rather than refused — which is why it should be mapped. The note's text is carried through from iPaaS.com as it arrives, with no trimming applied by this mapping. Subscribers whose notes can be long should validate in a staging environment that the text arrives whole before relying on this in production.

Parent: Add NCR Counterpoint Sale Ticket FROM iPaaS.com.

Mapping Filter

Filter Description.

Lines whose iPaaS.com type is Gift Card are excluded. A gift card sale is not a ticket line in Counterpoint at all — the card is transferred as a gift card instead — and a sale consisting only of gift cards is excluded by the parent collection's own filter before it reaches this one.

This filter is what makes several of this collection's mappings inert as shipped. The mappings that flag a gift card line, carry its card number, and decide whether it becomes a gift card or a store credit only take effect on lines this filter excludes, so as shipped no line is ever converted. Subscribers should leave them in place: if gift card lines are ever allowed through by relaxing this filter, they are what stops those lines from reaching Counterpoint as ordinary sale lines.

Source: SequenceNumber · Destination: SEQ_NO

This is a required field — NCR Counterpoint rejects the record without it. It is what keeps the ticket's lines in order and distinguishes one line from another on the same ticket. The sequence number from the iPaaS.com transaction line is carried through as it arrives.

Source: "S" · Destination: LIN_TYP

This is a required field — NCR Counterpoint rejects the record without it. It tells NCR Counterpoint what kind of line this is. The static value marks every line as a sale, which is what this collection creates. Counterpoint also recognizes values for returns, orders, backorders, special orders, layaways, and drop-ship orders. This is a genuine Counterpoint constant rather than an example, so it does not need changing for a typical install; returns reach Counterpoint through their own collections rather than by changing this value.

Source: ItemNumberFromSku(Sku) · Destination: ITEM_NO

This is a required field — NCR Counterpoint rejects the record without it, with Item number(ITEM_NO) is a required field. It is the item the line is selling. The formula takes the item number out of the iPaaS.com SKU.

iPaaS.com SKUs can carry more than the item number: a vertical bar separates the item number from the grid dimensions, and a caret separates the unit. The formula returns whatever comes before the first of these — so a SKU of SHIRT|BLUE|RED^3PAK yields an item number of SHIRT, while a plain SKU with neither marker is used as the item number unchanged. A line with no SKU supplies nothing.

The item number is used as it comes out of the SKU, and it must be an existing Counterpoint item. Presence is all that is checked during the transfer, not the item itself. An item number your installation does not have is accepted and stored on the line rather than being reported as a transfer error, and it then fails later — when the ticket is posted, or when Counterpoint comes to relieve stock for the line — rather than at the point of transfer. A line for an item that never reached Counterpoint therefore transfers successfully and goes unnoticed until the ticket is worked on.

The SKUs arriving from iPaaS.com consequently need to correspond to item numbers in your own Counterpoint installation. This mapping does not transfer the item, so subscribers should ensure products are already reaching Counterpoint before enabling this collection rather than relying on a transfer error to tell them a product is missing.

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

This is a recommended field. The first grid dimension of the item, taken out of the iPaaS.com SKU. Grid dimensions are how Counterpoint holds variations of the same item, such as size and color.

The formula reads the part of the SKU after the first vertical bar. Where the SKU has no grid dimensions, or has fewer than this one, the formula supplies an asterisk, which is how Counterpoint records that a dimension does not apply. Lines for items that are not grid items therefore transfer with an asterisk rather than empty, which is correct and expected. A line with no SKU supplies nothing.

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

This is a recommended field. The second grid dimension of the item, read from the part of the iPaaS.com SKU after the second vertical bar. As with DIM_1_UPR above, an asterisk is supplied where the SKU has no second dimension.

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

This is a recommended field. The third grid dimension of the item, read from the part of the iPaaS.com SKU after the third vertical bar. As with DIM_1_UPR above, an asterisk is supplied where the SKU has no third dimension.

Subscribers whose SKUs carry both grid dimensions and a unit should validate the dimensions arriving in Counterpoint in a staging environment before relying on this in production, since the last dimension is where the unit marker sits in the SKU.

Source: Qty · Destination: QTY_SOLD

This is a recommended field. It is the quantity the line sells, and it is what Counterpoint decrements the stocking location by. Counterpoint accepts the record without it and records 1 instead, so it should be mapped for accurate data — a line that arrives with no quantity is recorded as selling one of the item rather than being refused. It is also the quantity kit component lines are calculated from where EXPAND_KIT_CHILDREN below applies.

Source: QtyShipped · Destination: QTY_SHIPPED

This is a recommended field. How much of the line has shipped. On a sale ticket this normally matches the quantity sold, since a ticket records a completed sale rather than an outstanding order.

Source: SellingUnit · Destination: QTY_UNIT

This is a recommended field. The unit the item is sold in — each, case, pack, and so on. The value comes from a custom field on the iPaaS.com transaction line rather than a standard one, so subscribers should confirm it is being populated on their own transactions before relying on it; a line that arrives without one transfers with the unit empty.

Source: UnitPrice · Destination: PRC

This is a recommended field. It is the price the item actually sold for, per unit, and it is what the ticket charges. Counterpoint accepts the record without it, so it should be mapped for accurate data rather than to prevent a failure. This is the price after any discounting, as opposed to CALC_PRC below.

Source: OriginalUnitPrice · Destination: CALC_PRC

This is a recommended field. The price the item would have sold for before any discounting, per unit. Counterpoint holds it alongside the price actually charged so that the difference between the two is visible on the ticket. Where the line was not discounted, this matches PRC above.

Source: ExtendedPrice · Destination: EXT_PRC

This is a required field — NCR Counterpoint rejects the record without it, with Ext prc(EXT_PRC) is a required field. It is the line's total, and it is what the ticket's own totals are recalculated from. The extended price is the quantity multiplied by the price actually charged.

Source: ExtendedPrice · Destination: CALC_EXT_PRC

This is a required field — NCR Counterpoint rejects the record without it, with Calc ext prc(CALC_EXT_PRC) is a required field. It is Counterpoint's counterpart to EXT_PRC above, holding what the line would have come to before discounting.

Note that this mapping is supplied from the same source as EXT_PRC, so as shipped the two are always equal and the ticket shows no line-level discount even where the line was discounted — the per-unit prices in PRC and CALC_PRC above still differ. Subscribers who want the discount visible at the line level should map this to the extended original price instead; because the field is required, any replacement has to keep supplying a value rather than leave it unmapped. Subscribers who report on line discounting in Counterpoint should check this before enabling the collection.

Source: "Y" · Destination: HAS_PRC_OVRD

This is a recommended field — it is what stops NCR Counterpoint from recalculating the line's price. Counterpoint accepts the record without it and records N instead, meaning no price override, so it should be mapped for accurate data: a line that arrives without it is priced from Counterpoint's own price rules and the price the customer actually paid on the website is lost. The static value flags every line as having a price override.

This mapping is the reason PRC_OVRD_REAS below is populated, so that a line carrying a price override also records why. Subscribers should leave this in place unless they specifically want Counterpoint to reprice what arrives from iPaaS.com.

Source: "WEBSITE" · Destination: PRC_OVRD_REAS

This is a recommended field. It records why the price was overridden, and the template populates it because the line carries a price override set by HAS_PRC_OVRD above. Counterpoint accepts the record without it, so it should be mapped so that overridden pricing is explained in your Counterpoint reporting rather than to prevent a failure.

Whatever value is supplied must be a reason code configured in your own Counterpoint installation. Nothing checks that during the transfer. A reason code your installation does not have is accepted and stored on the line rather than being reported as a transfer error, and it then fails later — when the ticket is posted or used by another Counterpoint function — rather than at the point of transfer. 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 — a reason code that installation does not have is stored rather than refused, and surfaces later rather than as a transfer error.

Source: "Y" · Destination: HAS_TAX_OVRD

This is a required field — NCR Counterpoint rejects the record without it. It is what stops NCR Counterpoint from calculating its own tax on the line, so that the tax figures arriving from iPaaS.com are the ones the ticket uses. The static value flags every line as having a tax override.

This is the line-level counterpart to SAL_HAS_TAX_OVRD on Add NCR Counterpoint Sale Ticket FROM iPaaS.com, and although both are described as a tax override they are different fields and do not take the same values. They also differ in requiredness: a line has to carry a value here, whereas the ticket-level field can be left off. The same asymmetry separates this field from HAS_PRC_OVRD above, which is otherwise its closest analogue on the line. Subscribers changing how tax reaches Counterpoint need to consider both, along with Add NCR Counterpoint Sale Ticket Tax FROM iPaaS.com.

Source: EstimatedTaxAmount · Destination: TAX_AMT_ALLOC

This is a recommended field. The share of the ticket's tax that belongs to this line. It is the estimated tax from the iPaaS.com line rather than a figure recalculated from the ticket's total, so on tickets where the two are worked out differently the lines may not add up exactly to the ticket's tax. The ticket's own tax comes from Add NCR Counterpoint Sale Ticket Tax FROM iPaaS.com and is not derived from this field.

Source: "true" · Destination: EXPAND_KIT_CHILDREN

This is a control mapping rather than a value, so requiredness does not apply to it in the way it does to the fields above. EXPAND_KIT_CHILDREN is not a field subscribers will find on a Counterpoint ticket line and is not backed by the Counterpoint schema; it tells the integration what to do with a line before the ticket is sent.

When it is on, a line selling a kit has the kit's component lines added to the ticket alongside it, each one carrying the component's item number and selling unit, and a quantity worked out from the kit line's quantity multiplied by the component quantity. The components inherit the parent line's line type, price override flag and price override reason.

The expansion applies to miscellaneous kits only. Lines selling any other kind of kit, lines selling an item that is not a kit, lines whose components have already been added, and kits with no components are all left exactly as they arrived — nothing is added and nothing fails. Subscribers who sell kits other than miscellaneous kits should not expect their components to appear on the ticket.

Because this is a control mapping, turning it off changes what the ticket contains rather than what a field says: kit lines then transfer as a single line with no components.

Source: (Type == "Gift Card" ? true : false) · Destination: IS_GIFTCARD_LINE

This is a control mapping rather than a value, so requiredness does not apply to it in the way it does to the fields above. IS_GIFTCARD_LINE is not a field subscribers will find on a Counterpoint ticket line and is not backed by the Counterpoint schema. NCR Counterpoint does not treat a gift card sale as a line at all, whereas iPaaS.com does, and this mapping is what tells the integration which lines need converting from one to the other. A line flagged this way is taken off the ticket's lines and added to the ticket as a gift card instead.

In practice this collection's Mapping Filter already excludes gift card lines, so the formula always evaluates to false and no line is ever converted — the mapping only takes effect if a subscriber relaxes that filter. Subscribers should leave it in place: if gift card lines are ever allowed through, this is what stops them from reaching Counterpoint as ordinary sale lines.

Source: ReadFromStringDictionary(LineInfo, "GiftCardId") · Destination: GFC_NO

This is an optional field. Where a line is converted into a gift card by IS_GIFTCARD_LINE above, this is the gift card number carried across with it; it is staged on the line because that is where iPaaS.com holds the information, and it reaches Counterpoint on the gift card rather than on a ticket line.

As with IS_GIFTCARD_LINE, the collection's Mapping Filter means no line is converted as shipped, so this mapping has no effect unless a subscriber relaxes the filter. The gift card number is not guaranteed to be present on the line even then.

Source: "N" · Destination: CREATE_AS_STC

This is an optional field. Where a line is converted into a gift card by IS_GIFTCARD_LINE above, this decides whether Counterpoint creates a gift card or a store credit; the static value creates gift cards. Like GFC_NO above it is staged on the line and delivered on the gift card, and nothing reads it on a line that is not converted.

As shipped the collection's Mapping Filter means no line is ever converted, so this mapping has no effect unless a subscriber relaxes the filter.

Parent: Add NCR Counterpoint Sale Ticket FROM iPaaS.com.

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

This is a recommended field. It is the pay code Counterpoint books the payment against, and it decides which tender the money is recorded as. Counterpoint accepts the record without it, so it should be mapped for accurate data rather than to prevent a failure — a payment that arrives with no pay code is not booked against any tender. The translation converts the payment method arriving from iPaaS.com into a Counterpoint pay code.

The translation ships with these pairs:

The last two gift card rows are conditions rather than plain values: they look at the payment's method information to tell a gift card redemption from a store credit redemption, and send each to a different pay code.

Whatever pay code the translation produces must be a pay code configured in your own Counterpoint installation. Nothing checks that during the transfer. A pay code your installation does not have is accepted and stored on the payment rather than being reported as a transfer error, and it then fails later — when the ticket is posted, or when another Counterpoint function reads the payment — rather than at the point of transfer. Because the payments carrying an unconfigured code transfer successfully, the problem does not announce itself at the time it is introduced.

Two things therefore need attention before this collection is enabled. The pay codes on the right are the codes of the installation this template was built against, so subscribers or their MiSP should confirm each one exists in their own Counterpoint installation and replace any that do not. Note also that every card and wallet method translates to the cash pay code, which means the ticket does not distinguish a credit card payment from cash. Subscribers who reconcile tenders separately in Counterpoint should repoint these rows at the pay codes that match how they actually settle, rather than leaving them pooled.

Payment methods with no row here transfer with no pay code. Subscribers who add payment methods on the iPaaS.com side should add a matching row at the same time.

Source: Description · Destination: DESCR

This is a required field — NCR Counterpoint rejects the record without it, with Description(DESCR) is a required field. The payment's description as it arrives from iPaaS.com. This is what makes one payment distinguishable from another on tickets that carry several, particularly where they all translate to the same pay code through PAY_COD above.

Because the description is carried straight through from iPaaS.com, a payment that arrives without one is refused rather than transferred with the field empty. This is worth checking against your own payment methods before the collection is enabled, since it makes the description a prerequisite for the payment reaching Counterpoint at all rather than a reporting nicety.

Source: Amount · Destination: AMT

This is a recommended field. It is the amount the payment is worth. Counterpoint accepts the record without it and records 0 instead, so it should be mapped for accurate data — a payment that arrives with no amount records no money rather than being refused. The amount arrives from iPaaS.com and is used exactly as it arrives; the integration does not adjust it.

This is worth knowing for credit card payments that have been authorized but not yet captured. Such a payment transfers with whatever amount iPaaS.com reports for it, and is flagged as a final payment by FINAL_PMT below. Subscribers who do not want an uncaptured authorization to be booked at its full value must decide that here — either by replacing this mapping with a formula that supplies a different amount when the payment's status is authorized, or by using this collection's Mapping Filter to exclude authorized payments until they are captured. Both are subscriber decisions; the template as shipped does neither.

Source: Amount · Destination: ORD_AMT

This is a recommended field. It is what applies the payment to the ticket. Counterpoint holds the amount a payment is worth and the amount it applies to the document separately, and it accepts the record without this one, recording 0 instead — so a payment that is worth something but applies nothing is transferred rather than refused, and leaves the ticket looking unpaid. That makes it worth mapping for accurate data.

It is mapped from the same source as AMT above so that the two always agree, which is what makes the payment apply in full. Subscribers replacing either mapping should keep them consistent with each other.

Source: (Status == "Authorized" ? "Y" : "N") · Destination: FINAL_PMT

This is a recommended field. Marks whether the payment is the final one against the ticket. The formula derives it from the payment's status: a payment that has been authorized but not yet captured is flagged as final, and any other payment is not.

Subscribers should validate this behavior in a staging environment before relying on it in production, particularly on tickets carrying more than one payment, where more than one authorized payment would each be flagged as final.

Source:

Destination: GFC_NO

This is an optional field. The number of the gift card the payment redeemed. The formula first looks at what kind of card the payment used; if it was a gift card, it looks the card up in iPaaS.com and supplies its number, and if it was anything else — including a store credit — it supplies nothing.

This mapping and STC_NO below are a pair: Counterpoint holds gift card and store credit redemptions in two separate fields, and between them the two formulas put the number in whichever field is right for the card. Only one of them ever supplies a value for a given payment.

Where the payment did not redeem a card at all, where the card cannot be found in iPaaS.com, or where the payment carries no card reference, the mapping supplies nothing and the payment transfers without a card number rather than failing.

Source:

Destination: STC_NO

This is an optional field. The number of the store credit the payment redeemed. The formula works exactly as GFC_NO above does, but supplies the number only when the card was a store credit rather than a gift card.

Where a store credit number is supplied, it must be an existing store credit in your own Counterpoint installation. Nothing checks that during the transfer. A store credit number your installation does not have is accepted and stored on the payment rather than being reported as a transfer error, and it then fails later — when the ticket is posted, or when another Counterpoint function applies the redemption — rather than at the point of transfer.

Subscribers replacing either mapping should keep both deciding from the same source, so that a redemption cannot be written to both fields or to neither.

Parent: Add NCR Counterpoint Sale Ticket FROM iPaaS.com.

Source: "S" · Destination: TAX_DOC_PART

This is a recommended field — it tells NCR Counterpoint which part of the document the tax record belongs to. Counterpoint accepts the record without it and records S instead, so it should be mapped for accurate data. The static value marks it as sale tax, which is what this collection creates, and it matches the value Counterpoint would have supplied on its own. Counterpoint also recognizes values for order, layaway and foodstamp tax records. This is a genuine Counterpoint constant rather than an example, so it does not need changing for a typical install.

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, with Authority(AUTH_COD) is a required field. It is the tax authority the tax record is booked against, and it must be a tax authority configured in your own Counterpoint installation.

Only presence is checked during the transfer, not the value. An authority code your installation does not have is accepted and stored on the tax record rather than being reported as a transfer error, and it then fails later — when the ticket is posted, or when another Counterpoint function reads the tax record — rather than at the point of transfer. Subscribers or their MiSP should confirm the authority exists in Counterpoint before enabling this collection.

The formula is shaped to tell three situations apart: a taxed ticket inside the home region, a taxed ticket outside it, and an untaxed ticket. It decides which by taking the region from the ticket's primary shipping address, falling back to the primary billing address where there is no shipping region, and comparing it against a named region.

As shipped, all three branches return the same authority, so the formula always produces TN whatever the region and whatever the tax amount. Subscribers who need it can give each of the three situations a different authority; until they do, it has no effect on the result.

Placeholder value — replace during implementation: "TN" is an example tax authority and "Tennessee" an example region, not Counterpoint defaults. Replace them with a tax authority and region from your own Counterpoint installation before enabling this collection, giving each of the three branches the authority that is correct for it. This decision should be made together with TAX_COD on Add NCR Counterpoint Sale Ticket FROM iPaaS.com and RUL_COD below, which are shaped the same way and should agree with each other.

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, with Rule(RUL_COD) is a required field. It is the tax rule the tax record is booked against, within the authority set by AUTH_COD above, and it must be a tax authority rule configured in your own Counterpoint installation.

Only presence is checked during the transfer, not the value. A rule code your installation does not have is accepted and stored on the tax record rather than being reported as a transfer error, and it then fails later — when the ticket is posted, or when another Counterpoint function reads the tax record — rather than at the point of transfer. Subscribers or their MiSP should confirm the rule exists in Counterpoint, under the authority set alongside it, before enabling this collection.

The formula tells apart the same three situations, in the same way, from the same regions.

As shipped, all three branches return the same rule, so the formula always produces TAX whatever the region and whatever the tax amount. Subscribers who need it can give each situation a different rule.

Placeholder value — replace during implementation: "TAX" is an example tax rule and "Tennessee" an example region, not Counterpoint defaults. Replace them with a tax rule and region from your own Counterpoint installation before enabling this collection. Because a rule belongs to an authority, this mapping and AUTH_COD above must be changed together — a rule that does not belong to the authority set alongside it will not describe the tax correctly.

Source: Parent.TaxAmount · Destination: TAX_AMT

This is a recommended field. It is the tax the ticket charges, and it is the figure Counterpoint books. Counterpoint accepts the record without it, so it should be mapped for accurate data rather than to prevent a failure — a tax record that arrives with no amount books no tax, which is the opposite of what this collection exists to do. The amount is taken from the ticket's total tax as it arrives from iPaaS.com and is used as-is, because SAL_HAS_TAX_OVRD on the parent collection stops Counterpoint from working out its own.

The same amount is also written to the ticket header by SAL_TAX_AMT on Add NCR Counterpoint Sale Ticket FROM iPaaS.com. Subscribers replacing either mapping should keep the two consistent, since a tax record that disagrees with its own ticket header is difficult to reconcile afterwards.

Source: Parent.TaxAmount · Destination: NORM_TAX_AMT

This is a recommended field. The normal tax — what the tax would have been before any override or exemption was applied. Counterpoint holds it alongside the tax actually charged so that the difference between the two is visible.

As shipped this mapping is supplied from the same source as TAX_AMT above, so the two are always equal and the ticket shows no difference between the normal tax and the tax charged. This is correct for tickets whose tax arrives already calculated, which is the normal case for this integration. Subscribers who apply tax exemptions on the iPaaS.com side and want the exempted amount visible in Counterpoint should map this to the pre-exemption figure instead.

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.