iPaaS.com to NCR Counterpoint Deposit Ticket Mapping Documentation

This mapping collection writes deposit and gift card tickets from iPaaS.com into NCR Counterpoint. When an order taken in iPaaS.com collects money before the goods are sold — a deposit against a future order, or the sale of a gift card — iPaaS.com splits that money onto a ticket of its own, and this collection creates the corresponding ticket in Counterpoint. The collection carries the ticket number, the store, station, drawer and user the ticket is attributed to, the bill-to and ship-to party and address, the tax override details, and the link back to the Counterpoint order the ticket came from.

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 reaches this collection only when it is a ticket that iPaaS.com split off from an order, and only when that ticket is settled enough to belong in Counterpoint. Two kinds of ticket qualify, and the filter identifies them by the end of the transaction number:

Beyond that, the ticket must carry at least one payment, and the filter holds back three cases: a deposit whose payments are all still Authorized rather than captured, a gift card ticket that still has uncaptured payments, and a gift card ticket whose gift card lines are still pending or void. A ticket that already carries a captured payment is treated as settled and transfers as soon as it qualifies.

Removing the -D clause from the filter leaves only the -GC clause, so only gift card sale tickets are transferred and the deposit portion of an order is no longer written to Counterpoint at all. Subscribers who take gift card payments through iPaaS.com but settle deposits by another route can make that change deliberately. Subscribers relaxing any other part of this filter should expect tickets to reach Counterpoint before the money behind them is final.

Source: "BC" + TransactionNumber · Destination: TKT_NO

This is a required field — NCR Counterpoint rejects the record without it. The Counterpoint ticket number. The formula prefixes the iPaaS.com transaction number with two characters so that tickets arriving from iPaaS.com are recognizable in Counterpoint and cannot collide with ticket numbers created at the point of sale. Because the iPaaS.com transaction number already carries the -D or -GC suffix that identifies which portion of the order this is, the resulting ticket number distinguishes deposits from gift card tickets without further work.

Placeholder value — replace during implementation: "BC" is an example prefix, not a Counterpoint default. Replace it with a prefix that identifies these tickets in your own Counterpoint installation before enabling this collection. Keep the replacement to two characters — Counterpoint allocates limited space for the ticket number, and a longer prefix consumes room the transaction number needs.

Source: "O" · Destination: DOC_STAT

This is a recommended field. The document status Counterpoint records for the ticket. Counterpoint accepts the record without it and records O instead, which is the same value this mapping supplies, so it should be mapped for accurate data. Allowed values: O for open, F for completed, and C for cancelled. The static value creates every ticket as open, which is correct for a deposit or gift card ticket that has not yet been posted in Counterpoint. This is a genuine Counterpoint constant rather than an example, so it does not need changing for a typical install, and any replacement must be one of the three values above.

Source: "MAIN" · Destination: STR_ID

This is a required field — NCR Counterpoint rejects the record without it. The store the ticket is created in, and the value must be a store configured in your own Counterpoint installation. Counterpoint requires a store to be present, but it does not check the value against the stores configured in your installation as the ticket transfers: a store that is not configured is accepted by the transfer and stored, and then fails later, when the ticket 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 these tickets should be created in, taken from your own Counterpoint installation, before enabling this collection. Tickets from every source are attributed to whichever single store is set here, so subscribers running multiple stores should consider whether a fixed value is correct for their reporting, and replace it with a formula if not.

Source: "1" · Destination: STA_ID

This is a required field — NCR Counterpoint rejects the record without it. The station the ticket is created at, and the value must be a station configured in your own Counterpoint installation. A single-character value here is an identifier, not a flag — Counterpoint station ids are short, and this one names a station rather than switching a behavior on. Counterpoint requires a station to be present, but it does not check the value against the stations configured in your installation as the ticket transfers: a station that is not configured is accepted by the transfer and stored, and then fails later, when the ticket 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 ticket is attributed to. As with the station above, the single-character value is an identifier rather than a flag. Counterpoint accepts the ticket without a drawer, and it does not check the value against the drawers configured in your installation as the ticket transfers: a drawer that is not configured is accepted by the transfer and stored, and then fails later, when the ticket 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. Subscribers who reconcile drawers at the point of sale should give tickets arriving from iPaaS.com a drawer that reflects that they were not taken in person.

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 Counterpoint user recorded as having taken the ticket. A single-character value here is an identifier, not a flag — Counterpoint user ids are short. Counterpoint accepts the ticket without a user, and it does not check the value against the users configured in your installation as the ticket transfers: a user that does not exist is accepted by the transfer and stored, and then fails later, when the ticket 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 Point of Sale user id from your own Counterpoint installation before enabling this collection. Every ticket arriving from iPaaS.com is attributed to whichever single user is set here, so subscribers who report on activity by user should choose one that makes the source of these tickets obvious.

Source: "0" · Destination: TIMES_PRTD

This is a recommended field. A count of how many times the 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 correct starting value for a ticket that has just been created and never printed, and 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: CustomerFromEmail(EmailAddress) · Destination: CUST_NO

This is an optional field, but where it supplies a value that value must be an existing Counterpoint customer. Attaches the ticket to a Counterpoint customer. The formula searches Counterpoint for a customer whose first email address matches the email address on the iPaaS.com transaction. Where more than one customer matches, a customer flagged as an ecommerce customer wins; where several match and none is flagged, the first match is used. The formula matches on the email address alone, so subscribers whose Counterpoint records share email addresses across customers should confirm the ecommerce flag is set on the record they expect these tickets to land on. It does not create a customer that does not exist, so subscribers who want every ticket attached to a named customer should ensure customers are transferring to Counterpoint before enabling this collection.

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

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

This is an optional field. Tells Counterpoint whether the bill-to party is a person or a business. Allowed values: B for business and P for person. The formula derives the answer from the primary billing address rather than from a separate source: an address carrying a company is treated as a business, and one without a company is treated as a person. This keeps the name type consistent with BILL_NAM below, which is built from the same test. Subscribers replacing either mapping should keep both derived from the same source, since a ticket flagged as a business but carrying a person's name reads incorrectly everywhere Counterpoint shows the bill-to party.

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 shown on the ticket. The formula reads the primary billing address: where that address carries a company, the company becomes the name; otherwise the first and last name are joined with a space. This mirrors the way Counterpoint itself fills the name from the bill-to name type. The result is trimmed to 40 characters, so a long company name is cut rather than rejected. Where the transaction has no primary billing address, the mapping supplies nothing.

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

This is an optional field. The bill-to first name, read from the primary billing address. The formula trims the result to 15 characters before it is written, so a longer first name is cut rather than rejected. Where the transaction has no primary billing address, or that address has no first name, the mapping supplies nothing.

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

This is an optional field. The bill-to last name, read from the primary billing address. The formula trims the result to 25 characters before it is written, so a longer last name is cut rather than rejected. Where the transaction has no primary billing address, or that address has no last name, the mapping supplies nothing.

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, read from the primary billing address. The formula trims the result to 40 characters before it is written. Where the transaction has no primary billing address, or that line is empty, the mapping supplies nothing.

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, read from the primary billing address. The formula trims the result to 40 characters before it is written. Most addresses have no second line, and the mapping supplies nothing when it is empty.

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, read from the primary billing address. The formula trims the result to 40 characters before it is written. Most addresses have no third line, and the mapping supplies nothing when it is empty.

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

This is an optional field. The bill-to city, read from the primary billing address. The formula trims the result to 20 characters before it is written, which is short enough that some city names are cut. Where the transaction has no primary billing address, the mapping supplies nothing.

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

This is an optional field. The bill-to state or region, read from the primary billing address. The formula trims the result to 10 characters before it is written. Subscribers whose iPaaS.com addresses hold full region names rather than abbreviations should be aware that anything past the tenth character is cut, which can turn a spelled-out region into a value Counterpoint does not recognize for reporting. Replacing this mapping with one that supplies an abbreviation avoids that.

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

This is an optional field. The bill-to postal code, read from the primary billing address. The formula trims the result to 15 characters before it is written. Where the transaction has no primary billing address, the mapping supplies nothing.

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

This is an optional field. The bill-to country, read from the primary billing address. The formula trims the result to 20 characters before it is written. Unlike the equivalent mappings on some other collections in this integration, this one supplies no fallback country, so a transaction whose billing address has no country transfers with the country empty.

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

This is an optional field. The bill-to email address. Unlike the other bill-to mappings in this collection, this one reads the email address held on the transaction itself rather than on the primary billing address. The formula trims the result to 50 characters before it is written. This is the same value CUST_NO above uses to find the Counterpoint customer, so a ticket that failed to match a customer will still show the address it tried to match on.

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

This is an optional field. Tells Counterpoint whether the ship-to party is a person or a business. Allowed values: B for business and P for person. The formula derives the answer from the primary shipping address: an address carrying a company is treated as a business, one without a company as a person. This works the same way as BILL_NAM_TYP above, and the same advice applies — keep it derived from the same source as the name it describes.

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 shown on the ticket. The formula tests the primary shipping address for a company: where there is none, the first and last name from the primary shipping address are joined with a space. The result is trimmed to 40 characters. Where the transaction has no primary shipping address, the mapping supplies nothing. Deposit and gift card tickets often carry no shipping address at all, since nothing is being shipped, and an empty ship-to name is normal in that case.

Where the primary shipping address does carry a company, the name written is the company from the primary billing address rather than the shipping one. 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 ticket, and should replace this mapping with one that reads the shipping company if the ship-to name matters to them. Note that SHIP_NAM_TYP below is derived from the shipping address's company, so a transaction with a shipping company but no billing company is flagged as a business while the name itself comes out empty.

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

This is an optional field. The ship-to first name, read from the primary shipping address. The formula trims the result to 15 characters before it is written. Where the transaction has no primary shipping address, the mapping supplies nothing.

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

This is an optional field. The ship-to last name, read from the primary shipping address. The formula trims the result to 25 characters before it is written. Where the transaction has no primary shipping address, the mapping supplies nothing.

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, read from the primary shipping address. The formula trims the result to 40 characters before it is written. Where the transaction has no primary shipping address, the mapping supplies nothing.

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, read from the primary shipping address. The formula trims the result to 40 characters before it is written. Most addresses have no second line, and the mapping supplies nothing when it is empty.

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, read from the primary shipping address. The formula trims the result to 40 characters before it is written. Most addresses have no third line, and the mapping supplies nothing when it is empty.

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

This is an optional field. The ship-to city, read from the primary shipping address. The formula trims the result to 20 characters before it is written, which is short enough that some city names are cut. Where the transaction has no primary shipping address, the mapping supplies nothing.

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

This is an optional field. The ship-to state or region, read from the primary shipping address. The formula trims the result to 10 characters before it is written, so the same caution applies as for BILL_STATE above — spelled-out region names are cut at the tenth character. This value also matters beyond the address itself: the tax mappings on Add/Update NCR Counterpoint Deposit Ticket Tax FROM iPaaS.com read the shipping region to decide which tax authority applies.

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

This is an optional field. The ship-to postal code, read from the primary shipping address. The formula trims the result to 15 characters before it is written. Where the transaction has no primary shipping address, the mapping supplies nothing.

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

This is an optional field. The ship-to country, read from the primary shipping address. The formula trims the result to 20 characters before it is written. As with BILL_CNTRY above, no fallback country is supplied, so an address without one transfers with the country empty.

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 ship-via code recorded on the ticket, read from the shipping method on the primary shipping address. The value is passed through unchanged, so what Counterpoint receives is whatever the iPaaS.com shipping method is called. Counterpoint identifies shipping methods by its own ship-via codes, and the two naming schemes rarely agree on their own, so this mapping as shipped routinely sends a value Counterpoint does not know.

Counterpoint accepts the ticket without a ship-via code, and it does not check the value against the ship-via codes configured in your installation as the ticket transfers: a code that is not configured is accepted by the transfer and stored, and then fails later, when the ticket is posted or used by another Counterpoint function, rather than being reported as a transfer error. Subscribers or their MiSP should confirm that the shipping method values their transactions carry correspond to ship-via codes configured in their own Counterpoint installation before enabling this collection, and validate the behavior in a staging environment before relying on it in production. Where the two do not line up, replacing this mapping with a Lookup Translation converts the names as they transfer. Deposit and gift card tickets frequently carry no shipping address, in which case the mapping supplies nothing.

Source: "WEBSITE" · Destination: TAX_OVRD_REAS

This is an optional field, but where it is mapped the value must be a reason code configured in your own Counterpoint installation. The reason recorded against the ticket for overriding tax. The integration calculates tax on the iPaaS.com side and hands Counterpoint the finished figures rather than letting Counterpoint compute them, which is what makes an override reason relevant on every ticket this collection creates.

Counterpoint accepts the ticket without a reason code, and it does not check the value against the reason codes configured in your installation as the ticket transfers: a reason code that is not configured is accepted by the transfer and stored, and then fails later, when the ticket 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 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: "WEBSITE" · Destination: TAX_EXEMPT_NO

This is a recommended field. The tax exemption number recorded against the ticket. Counterpoint accepts the record without it, but where the ticket overrides tax and charges none, the exemption number is what documents the exemption — so it should be mapped for accurate data. Because this collection hands Counterpoint finished tax figures rather than letting it compute them, that condition is reached routinely, which is why the mapping ships populated rather than empty.

Placeholder value — replace during implementation: WEBSITE is an example value, not a Counterpoint default. Replace it with a value that identifies these tickets in your own Counterpoint installation before enabling this collection. Subscribers who track genuine tax exemption numbers per customer should be aware that a static value here records the same number on every ticket, and should replace it with a formula if their reporting depends on the real one.

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

This is an optional field. Links the ticket back to the Counterpoint order it came from, by looking up the Counterpoint document that the originating iPaaS.com transaction was previously transferred to. It is not always populated, and that is expected: a gift card ticket whose order contained nothing but gift card lines has no corresponding order in Counterpoint to point at, because such an order is not transferred. Where the originating order has not reached Counterpoint, the mapping supplies nothing and the ticket is created unlinked. For deposit tickets this rarely happens, since the Mapping Filter already holds a deposit back until its order has transferred.

Source: "0" · Destination: ORIG_ORD_AMT_DUE

This is an optional field. The amount still due on the originating order, as recorded against this ticket. The static zero reflects that the deposit or gift card ticket settles itself in full at the moment it transfers — the payments on the ticket cover it, which is what the Mapping Filter above checks before allowing the transfer at all. This is a genuine value rather than an example. Subscribers who want the ticket to carry the balance remaining on the wider order should replace it with a formula that reads that balance from the originating transaction, rather than changing the static to another fixed number.

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

Mapping Filter

Filter Description.

Only lines whose iPaaS.com type is Gift Card are written to Counterpoint by this collection. Ordinary product lines are not the business of this collection and are left to the line collections that handle them.

Source: "true" · Destination: IS_GIFTCARD_LINE

This is a control mapping rather than a value, and removing it leaves the integration with no way to tell where the line belongs. It is not backed by Counterpoint's own schema, so no rejection rule applies to it: IS_GIFTCARD_LINE is not a column subscribers will find in their Counterpoint database. Counterpoint records the sale of a gift card separately from the sale of a product, so before the ticket is sent, the integration converts every line flagged here into a gift card record on the ticket rather than a product line.

That conversion is worth understanding before changing anything else in this collection, because it decides which of the mappings below actually reach Counterpoint. The gift card record has room for the gift card code, the gift card number, the description, the amount and the create-as-store-credit flag. The remaining mappings in this collection are set on the line, but the gift card record has nowhere to put them, so they are not carried across: the quantity, the quantity shipped, the unit price, the sequence number, the allocated tax and the tax override flag all stop at the conversion. They are noted individually below.

Because the Mapping Filter already restricts this collection to gift card lines, the static value is correct for every line that reaches it. This is a genuine constant rather than an example.

Source: "GC" · Destination: GFC_COD

This is a recommended field. The gift card code is what tells Counterpoint how to treat the card being sold, so it should be mapped for a card that behaves correctly. Like IS_GIFTCARD_LINE above it is not backed by Counterpoint's own line schema — it belongs to the gift card record the line becomes — so no rejection rule applies to it. The value carries through the conversion described in IS_GIFTCARD_LINE above onto the gift card record.

Placeholder value — replace during implementation: "GC" is an example gift card code, not a Counterpoint default. Replace it with a gift card code from your own Counterpoint installation, or create one matching it, before enabling this collection.

Where store credits are in use, the code supplied here must be one Counterpoint has configured to create store credits — a code that is not set up for store credits will not produce store credits, whatever CREATE_AS_STC below is set to. The same code is supplied by the GFC_COD mapping on Add/Update NCR Counterpoint Gift Card FROM iPaaS.com, and the two should be changed together so that a card sold on a ticket and a card transferred on its own are created the same way.

Source: return await GetGiftCardRedemptionNumberAsync(LineInfo); · Destination: GFC_NO

This is a recommended field. It is the number of the card the customer is buying, and a gift card sale that does not say which card was sold cannot be reconciled against the card itself, so it should be mapped for accurate data. Like the two mappings above it is not backed by Counterpoint's own line schema, so no rejection rule applies to it. The formula reads the gift card identifier held on the iPaaS.com line and converts it to the gift card number Counterpoint knows. Where the line carries no gift card identifier, or the card cannot be found, the formula supplies nothing.

No manual sequencing is needed to make this work. When a deposit ticket is transferred, the integration checks the cards behind its gift card lines first and transfers any that Counterpoint does not yet know about, so the card exists by the time this mapping resolves against it. Where the card already exists in Counterpoint and its balance already matches, the transfer is skipped rather than repeated. This is also why the parent collection's Mapping Filter holds back a gift card ticket whose cards are still pending or void: a card in either state is not one the integration should be creating in Counterpoint yet.

The value carries through the conversion described in IS_GIFTCARD_LINE above onto the gift card record.

Source: "N" · Destination: CREATE_AS_STC

This is an optional field, and it is not backed by Counterpoint's own line schema, so no rejection rule applies to it. Tells Counterpoint whether the card being sold should be created as a store credit rather than a gift card. Counterpoint holds the two separately, and this flag selects between them. The value carries through the conversion described in IS_GIFTCARD_LINE above onto the gift card record.

Placeholder value — replace during implementation: "N" is an example setting, not a Counterpoint default. As it ships it creates a gift card, never a store credit, for every line this collection admits. Subscribers who sell store credits through iPaaS.com should replace the static with a formula that decides per line before enabling this collection — the equivalent decision is made on Add/Update NCR Counterpoint Gift Card FROM iPaaS.com by reading the iPaaS.com gift card type, and the same source is available here. Subscribers who do not sell store credits can leave it as it ships.

This flag works together with GFC_COD above: a store credit needs both this flag set and a gift card code that Counterpoint has configured to create store credits.

Source: Description · Destination: DESCR

This is a required field — NCR Counterpoint rejects the record without it, raising Description(DESCR) is a required field. The description of the gift card sale, carried straight from the iPaaS.com line with no formula. It carries through the conversion described in IS_GIFTCARD_LINE above onto the gift card record, where it is the text that identifies the sale to anyone looking at the ticket in Counterpoint.

Counterpoint allocates limited space for a description and this mapping does not trim the value, so subscribers whose iPaaS.com line descriptions are long should validate the behavior in a staging environment before relying on it in production, and replace this mapping with a formula that trims the result if their descriptions do not fit.

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. It is also the money the gift card sale is worth, so a sale without it would record nothing even if it were accepted. The extended price for the line, carried straight from the iPaaS.com line, held to two decimal places.

This is the mapping that decides the value of the card sale in Counterpoint. It carries through the conversion described in IS_GIFTCARD_LINE above and becomes the amount on the gift card record. Note that it is the extended price rather than the unit price that becomes the amount, so a line selling more than one card at once transfers as a single gift card record carrying the combined value rather than as one record per card. Subscribers who sell multiple cards on one line should confirm that this is what they want before enabling the collection.

Source: UnitPrice · Destination: PRC

This is an optional field. The price per unit from the iPaaS.com line, carried straight through. The gift card record the line becomes has no unit price of its own — it carries the amount supplied by EXT_PRC above instead — so this value is set on the line but does not reach Counterpoint. Subscribers should not rely on changing this mapping to alter the value of a card sale; EXT_PRC is the mapping that does that.

Source: Qty · Destination: QTY_SOLD

This is an optional field. The quantity from the iPaaS.com line, carried straight through. As with PRC above, the gift card record the line becomes has no quantity of its own, so this value is set on the line but does not reach Counterpoint. The value of a line selling several cards is carried by EXT_PRC above instead.

Source: QtyShipped · Destination: QTY_SHIPPED

This is an optional field. The quantity already shipped against the line, carried straight from the iPaaS.com line. Gift cards sold through iPaaS.com are not usually shipped, so this is normally zero or empty. As with QTY_SOLD above, the gift card record the line becomes has no quantity shipped of its own, so this value is set on the line but does not reach Counterpoint.

Source: SequenceNumber · Destination: SEQ_NO

This is a required field — NCR Counterpoint rejects the record without it, raising Sequence #(SEQ_NO) is a required field. The position of the line on the transaction, carried straight from the iPaaS.com line's sequence number. On an ordinary product line this is what keeps the Counterpoint lines in the same order as the source.

Two facts about this mapping are worth holding apart. Counterpoint's line schema requires the sequence number and rejects a line that arrives without one, so the mapping must stay in place. At the same time, on a gift card line the value is not carried into the gift card record the line becomes, so subscribers should not rely on it to order gift card sales within a ticket. It is required, and it is discarded — the requirement is the line schema's, and the discarding is the conversion's.

Source: EstimatedTaxAmount · Destination: TAX_AMT_ALLOC

This is an optional field. The share of the transaction's tax that belongs to this line, carried straight from the iPaaS.com line. The gift card record the line becomes has no tax of its own, so this value is set on the line but does not reach Counterpoint.

The sale of a gift card is not normally taxed — tax is charged when the card is spent, not when it is bought — which is consistent with Add/Update NCR Counterpoint Deposit Ticket Tax FROM iPaaS.com writing a zero tax record for these tickets. Subscribers whose iPaaS.com gift card lines carry a tax amount should treat that as a signal to check how their source system is configured, rather than expecting this mapping to carry the tax into Counterpoint.

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 the other yes/no flags reaching this collection, this one has no default behind it, so it must be supplied on every line. Allowed values: Y and N; Counterpoint accepts nothing else.

As with SEQ_NO above, the requirement and the outcome pull in different directions and both are true. On an ordinary product line this flag tells Counterpoint not to calculate tax for itself and to use the amount supplied instead. On a gift card line it is set on the line but is not carried into the gift card record the line becomes, so its value does not reach Counterpoint — yet the line schema still requires it to be present. This is a genuine Counterpoint constant rather than an example, and subscribers should leave it as it ships rather than removing it — the tax position of these tickets is settled by Add/Update NCR Counterpoint Deposit Ticket Tax FROM iPaaS.com and by the tax override fields on the parent collection, not here.

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

Mapping Filter

Filter Description.

Only payments that have moved past authorization are written to Counterpoint. A deposit ticket exists to record money actually taken, so a payment still sitting in an Authorized state has nothing to record yet and is skipped.

Subscribers who relax this filter should be aware that the amount mapping has no branch that zeroes the amount for an authorized payment — it does not need one, because this filter and the parent's filter have already excluded those payments. An authorized payment admitted by a relaxed filter would record a deposit that has not actually been collected.

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 recorded against the payment — it tells Counterpoint which tender the money came in through. 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. Rather than passing the iPaaS.com payment method straight through, this mapping runs it through a translation that converts each method into a Counterpoint pay code.

Counterpoint does not check the pay code against the pay codes configured in your installation as the payment transfers: a pay code that is not configured is accepted by the transfer and stored, and then fails later, when the ticket 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:

Two of the rows are conditions rather than plain values: they separate a gift card redemption from a store credit redemption by inspecting the payment, since both arrive as the same payment method. This is the same translation the other payment collections in this integration use, so a change made here applies to those as well.

This translation needs review before the collection is enabled. As it ships, every card and wallet method resolves to the cash pay code, which means a deposit taken on a card is recorded in Counterpoint as cash and will not be separable in a Counterpoint cash drawer or deposit report — a real concern for deposits specifically, since a deposit is money held against a future order and subscribers commonly reconcile it by tender. The pay codes on the right are also configured per Counterpoint installation, so codes that work in a demonstration company are not necessarily ones your installation knows. Subscribers or their MiSP should replace the destination values with pay codes from their own Counterpoint installation, and split the card methods onto their own pay codes where card and cash need to be reported separately. The sibling collection Add/Update NCR Counterpoint Payment Method TO iPaaS.com brings Counterpoint's own pay codes into iPaaS.com and is a useful reference when doing so.

A payment method with no matching row in the translation supplies nothing, so subscribers should also confirm that every method their source system can produce appears here.

Source: Amount · Destination: AMT

This is a recommended field — it is the money the deposit ticket records. Counterpoint accepts the record without it and records 0 instead, which is a payment that records nothing, so it should be mapped for accurate data. The iPaaS.com payment amount is passed straight through with no formula, held to two decimal places, so the value Counterpoint receives is the value iPaaS.com holds.

Unlike the equivalent mapping on Add NCR Counterpoint Order Payment FROM iPaaS.com, this one has no branch that zeroes the amount for an authorized payment. It does not need one: the Mapping Filter above has already excluded authorized payments, and the Mapping Filter on the parent collection has already held the whole ticket back until at least one payment is captured. Every payment that reaches this mapping represents money taken, so its real amount is what belongs on the ticket. Subscribers who relax either filter should revisit this mapping, because an authorized payment admitted by a relaxed filter would record a deposit that has not actually been collected.

Source:

Destination: GFC_NO

This is an optional field. The number of the gift card the deposit was paid with. The formula first works out whether the payment is a gift card redemption or a store credit redemption, since both arrive as the same payment method. Where it is a gift card redemption, the formula reads the gift card identifier from the payment and converts it to the gift card number Counterpoint knows. Where it is anything else, including a store credit redemption, the formula supplies nothing.

This works together with STC_NO below, which handles the store credit case. Exactly one of the two supplies a value for any gift card payment, so a payment cannot be recorded against both.

No manual sequencing is needed to make this work. When a deposit ticket is transferred, the integration checks the cards behind its gift card payments first and transfers any that Counterpoint does not yet know about, so the card exists by the time this mapping resolves against it.

Source:

Destination: STC_NO

This is an optional field, but where it supplies a value that value must be an existing store credit in your own Counterpoint installation. The number of the store credit the deposit was paid with. The formula mirrors GFC_NO above: it works out whether the payment is a gift card redemption or a store credit redemption, and where it is a store credit redemption it reads the identifier from the payment and converts it to the store credit number. Where it is anything else, including a gift card redemption, the formula supplies nothing.

Counterpoint accepts the payment without a store credit number, and it does not check the value against the store credits held in your installation as the payment transfers: a store credit that does not exist is accepted by the transfer and stored, and then fails later, when the ticket is posted or used by another Counterpoint function, rather than being reported as a transfer error. Subscribers or their MiSP should confirm the store credits their payments redeem exist in Counterpoint before enabling this collection.

Counterpoint holds gift cards and store credits separately, which is why the two mappings exist rather than one. Subscribers whose Counterpoint installation does not use store credits will find this mapping never supplies a value, and can leave it in place.

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

Mapping Filter

Filter Description.

The filter does two things. The first half admits the transaction's own tax rather than the tax held on each line, so this collection writes exactly one tax record per ticket, built from the transaction as a whole.

The second half restricts it to gift card tickets — the tickets whose transaction number ends in -GC. Deposit tickets, whose numbers end in -D, get no tax record from this collection at all: a deposit is money held against a future order, and the tax on that order is settled when the order itself is sold rather than when the deposit is taken.

Source: ((Parent.Transaction_Parent.TaxAmount > 0) && (Coalesce((string)(FieldFromFirstMatch(Parent.Transaction_Parent.Addresses, "IsPrimaryShipping == true", "Region")),(string)(FieldFromFirstMatch(Parent.Addresses, "IsPrimaryBilling == true", "Region"))) == "Tennessee") ? "TN" : (((Parent.Transaction_Parent.TaxAmount > 0) && !(Coalesce((string)(FieldFromFirstMatch(Parent.Transaction_Parent.Addresses, "IsPrimaryShipping == true", "Region")),(string)(FieldFromFirstMatch(Parent.Transaction_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 ticket's tax record is filed under, 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 ticket 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 ticket into one of three tax situations: a ticket whose originating order carried tax and whose region is the named home state, one whose originating order carried tax and whose region is anywhere else, and one whose originating order carried no tax. The region and the tax amount are both read from the order the gift card ticket was split from, not from the ticket itself — the ticket records the sale of the card, while the order is where the customer's address and tax were settled.

As shipped, all three branches supply the same authority, so the formula currently produces one authority for every ticket 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 carries the same example region and must be changed to agree with whatever is set here.

Subscribers who do give each situation its own authority should check which address the formula reads before relying on it. Where the originating order has no shipping address, this formula falls back to the billing address held on the ticket, while RUL_COD below falls back to the billing address held on the originating order. As shipped the difference has no effect, because every branch produces the same value — but it matters as soon as the branches differ, and the two mappings should be made to agree as part of that change.

Source: ((Parent.Transaction_Parent.TaxAmount > 0) && (Coalesce((string)(FieldFromFirstMatch(Parent.Transaction_Parent.Addresses, "IsPrimaryShipping == true", "Region")),(string)(FieldFromFirstMatch(Parent.Transaction_Parent.Addresses, "IsPrimaryBilling == true", "Region"))) == "Tennessee") ? "TAX" : (((Parent.Transaction_Parent.TaxAmount > 0) && !(Coalesce((string)(FieldFromFirstMatch(Parent.Transaction_Parent.Addresses, "IsPrimaryShipping == true", "Region")),(string)(FieldFromFirstMatch(Parent.Transaction_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 ticket's tax record is filed under, 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 ticket 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 and the same tax amount from the order the gift card ticket was split from. As shipped, all three branches supply the same rule, so the formula currently produces one rule for every ticket 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: "O" · 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, filing the tax against the sale part rather than the order part this mapping intends, 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.

The static value files the tax record against the order part, which is what a gift card ticket needs: the ticket is the deposit side of an order rather than a completed sale over the counter. This differs from the refund collections in this integration, which file their tax against the sale part because a refund is a completed transaction. This is a genuine Counterpoint constant rather than an example and does not need changing for a typical install.

Source: 0 · Destination: NORM_TAX_AMT

This is a recommended field. The tax that would normally have applied, held to two decimal places. 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.

The formula supplies a literal zero rather than reading anything from the transaction. This says that no tax would normally have applied to the ticket, which is the correct position for a gift card sale: buying a gift card is not a taxable event, and tax is charged when the card is spent instead. Because this mapping and TAX_AMT below both supply zero, Counterpoint is told that the tax charged matches the tax expected, and nothing looks overridden.

Source: 0 · Destination: TAX_AMT

This is a recommended field. The tax recorded against the gift card ticket, held to two decimal places. Counterpoint accepts the record without it, but this is the mapping that states the tax on the ticket, so it should be mapped for accurate data.

The formula supplies a literal zero, so every gift card ticket transfers with a tax record carrying no tax. This is deliberate rather than a gap: the record exists to state positively that the ticket is untaxed and to file that statement under the authority and rule the mappings above supply, which is what keeps Counterpoint's tax reporting complete. It is also consistent with the rest of the family — the TAX_AMT_ALLOC mapping on Add NCR Counterpoint Deposit Ticket Gift Card Line FROM iPaaS.com does not carry line tax into Counterpoint either.

Subscribers whose jurisdiction taxes the sale of a gift card rather than its use should not simply change this literal. The zero here works together with the zero above, with the tax override fields on the parent collection, and with the way gift card lines are converted before the ticket is sent — all four decide the ticket's tax position together, and taxing these tickets is a change to the family rather than to this mapping. Subscribers in that position should validate any such change in a staging environment before relying on it in production.

Errors raised while transferring these records surface at Dashboard / Integration Monitoring / Error Logs. The specific messages, their causes and their resolutions are documented in NCR Counterpoint Error Messages. A record stopped by an error is not retried automatically; it must be resolved manually.

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