This mapping collection writes gift cards from iPaaS.com into NCR Counterpoint. A card that Counterpoint does not yet hold is created; a card it already holds is updated. The collection carries the card's number and description, the value it was issued for, its remaining balance, its issue and expiry dates, and the links back to the customer the card was issued to and the ticket it was sold on.

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.

Only cards whose iPaaS.com status is neither Pending nor Void are written to Counterpoint. A card still awaiting issue, and a card that has been voided, are skipped. Subscribers who relax this filter should be aware that the Current amount mapping zeroes the balance of a voided card, so that a void cannot leave spendable value behind in Counterpoint — that safeguard only takes effect if voided cards are allowed through.

Source: Number · Destination: GFC_NO

This is a required field — NCR Counterpoint rejects the record without it, raising Gift card #(GFC_NO) is a required field. It is the gift card number, and a card transferred without one has nothing identifying it. Counterpoint stores the number as text of up to 30 characters, and a longer number is shortened to fit rather than refused — so subscribers whose card numbers can exceed 30 characters should confirm the stored number is still the one their cards carry. When the card is a store credit, this value is saved as the store credit number instead — the two are held separately in Counterpoint, and the IsStoreCredit mapping in this collection decides which.

Source: Description · Destination: DESCR

This is a required field — NCR Counterpoint rejects the record without it, raising Description(DESCR) is a required field. The card's description, which Counterpoint stores as text of up to 30 characters. This is a mismatch subscribers need to plan for: iPaaS.com treats a gift card description as optional, so a card whose iPaaS.com description is empty is rejected by Counterpoint rather than transferred. A description longer than 30 characters is a separate matter — it is shortened to fit rather than refused, and the trimmed part is not recorded anywhere.

Subscribers who want a fallback description on cards that arrive without one, or who want control over how a long description is shortened rather than accepting a cut at 30 characters, should replace this mapping with a formula that supplies a fallback and trims the result. Subscribers should validate the behavior in a staging environment before relying on it in production.

Source:

Destination: GFC_COD

This field is required in practice. Counterpoint accepts the record without it and the transfer succeeds, but a card created without a gift card code has nothing telling Counterpoint how to treat it, and store credits will not be created correctly. The gift card code Counterpoint uses when creating the card. The formula checks whether this card has been sent to Counterpoint before. If it has not, the formula supplies the code so the card can be created; if it has, the formula supplies nothing, which leaves the existing card's code untouched on later updates. This is what stops an update from re-coding a card that already exists.

The value supplied must be a gift card code configured in your own Counterpoint installation. A code that is not configured there is accepted by the transfer and stored on the card rather than being reported as a transfer error, and then fails later — when the card is used, or when another Counterpoint function reads it. Subscribers or their MiSP should confirm the code exists in Counterpoint before enabling this collection.

Placeholder value — replace during implementation: the code this formula supplies is an example value, 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. This is why it matters: an unconfigured code is not refused at transfer time — it is accepted and stored, and the problem appears later rather than as an error you can trace back to the transfer that caused it.

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 the IsStoreCredit mapping decides.

Source: (Type == "Store Credit" ? true : false) · Destination: IsStoreCredit

This is a required field — it is a control mapping rather than a value, and removing it leaves the integration with no way to decide where the record belongs. Decides whether the record is written to Counterpoint as a gift card or as a store credit. IsStoreCredit is not a column subscribers will find in their Counterpoint database — Counterpoint keeps gift cards and store credits in two separate places, and this mapping selects between them. When the iPaaS.com gift card type reads as a store credit, the record is written as a store credit; otherwise it is written as a gift card. Because this decides the destination rather than a value, changing it changes where every card lands.

Source: "G" · Destination: CREATE_METH

This is a recommended field. Records how the card came to exist. Counterpoint accepts the record without it and records S, meaning a store credit was issued, instead — so it should be mapped for accurate data. The static value marks cards arriving from iPaaS.com as a gift certificate sold, which is correct for gift cards created by a sale. Counterpoint also accepts a value meaning manually created. This is a genuine Counterpoint constant rather than an example, so it does not need changing for a typical install.

Source: "MAIN" · Destination: ORIG_STR_ID

This is a required field — NCR Counterpoint rejects the record without it, raising Store(ORIG_STR_ID) is a required field. It is the store the card is attributed to, which Counterpoint stores as text of up to 10 characters; a longer value is shortened to fit rather than refused. The value must also be a store configured in your own Counterpoint installation. A value that is not a configured store is accepted by the transfer and stored rather than reported as a transfer error, and then fails later — when the card is used, or when another Counterpoint function reads it — rather than at the point that caused it.

Placeholder value — replace during implementation: "MAIN" is an example store id, not a Counterpoint default. Replace it with the id of the store the cards should be attributed to in your own Counterpoint installation, and do so before enabling this collection. That id must be a store configured there, for the reason above: an id that is not is accepted and stored rather than refused, and the consequences appear later rather than as a transfer error. Cards from every location 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: return await GetExternalIdAsync(CustomerId, "Customer", SpaceportSystemId); · Destination: ORIG_CUST_NO

This is an optional field. Counterpoint accepts the card without it and the transfer succeeds either way. Links the card to the customer it was issued to, by looking up the Counterpoint customer that the iPaaS.com customer was previously transferred to. If that customer has not been transferred to Counterpoint, or the card has no customer, the mapping supplies nothing and the card is created without a customer link. It does not transfer the customer as a prerequisite, so subscribers who want cards linked to customers should ensure customers are transferring to Counterpoint before enabling this collection. Counterpoint stores the customer number as text of up to 15 characters.

Where a value is supplied, it must be an existing Counterpoint customer. As shipped, the mapping only supplies a number it has read back from Counterpoint's own record of a previous customer transfer, so it satisfies that on its own. It matters where a customer linked this way has since been removed from Counterpoint, or where a subscriber replaces this mapping with one that supplies numbers from elsewhere: a customer number that does not exist in Counterpoint is accepted by the transfer and stored on the card rather than being reported as a transfer error, and then fails later — when the card is used, or when another Counterpoint function reads it. Subscribers replacing this mapping should confirm the numbers it produces exist in Counterpoint before enabling this collection.

Source: return await GetExternalIdForGiftCardTicketAsync(TransactionId, SpaceportSystemId); · Destination: ORIG_DOC_ID

This is an optional field. Links the card back to the Counterpoint ticket it was sold on, by looking up the Counterpoint document that the iPaaS.com transaction was previously transferred to. If that transaction has not reached Counterpoint, or the card was not sold against one, the mapping supplies nothing and the card is created without a ticket link.

Source: (Status == "Void" ? 0 : Balance) · Destination: CURR_AMT

This is a recommended field. It is the card's remaining value, held to two decimal places. Counterpoint accepts the record without it and records 0 instead, so it should be mapped for accurate data — a card transferred without it carries no spendable balance. The formula zeroes the balance for voided cards so that a void cannot leave spendable value behind in Counterpoint. In practice this collection's Mapping Filter already excludes voided cards, so the zeroing branch only takes effect if a subscriber relaxes that filter — it is a safeguard rather than part of the normal flow. Subscribers who do relax the filter should leave the formula in place.

Source: OriginalAmount · Destination: ORIG_AMT

This is a required field — NCR Counterpoint rejects the record without it, raising Original amount(ORIG_AMT) is a required field. It is the value the card was originally issued for, held to two decimal places. Separately from that, Counterpoint does not accept a negative original amount, so a card whose iPaaS.com original amount is negative is also rejected rather than transferred — an empty amount and a negative amount are refused for different reasons. Subscribers should confirm this value is populated in iPaaS.com before enabling the collection, so that cards arrive carrying the value they were issued for.

Source: DateOnly(PurchaseDate) · Destination: ORIG_DAT

This is an optional field. The date the card was issued. Counterpoint stores this as a date with no time component and rejects a value carrying one, which is why the formula strips the time rather than passing the iPaaS.com value straight through. Subscribers replacing this mapping must keep that behavior — supplying a purchase date with a time attached causes the transfer to be rejected.

Source: DateOnly(ExpirationDate) · Destination: EXP_DAT

This is an optional field. The date the card expires; cards with no expiry transfer with it empty. As with the issue date, Counterpoint stores this as a date with no time component and rejects a value carrying one, which is why the formula strips the time. Subscribers replacing this mapping must keep that behavior. This mapping works together with NO_EXP_DAT below, which tells Counterpoint whether an expiry applies at all.

Source: (IsEmpty(ExpirationDate) ? "Y" : "N") · Destination: NO_EXP_DAT

This is a recommended field. Allowed values: Y and N; Counterpoint accepts nothing else. Marks whether the card is one that never expires. Counterpoint accepts the record without it and records N instead, so it should be mapped for accurate data. The formula derives it from the expiry date rather than from a separate source: a card arriving from iPaaS.com with no expiry date is flagged as never expiring, and a card with one is flagged as expiring. This keeps the flag and the date consistent, which matters because Counterpoint treats them as a pair — a card flagged as never expiring but carrying a date, or the reverse, produces a card whose expiry behavior does not match its data. Subscribers replacing this mapping should keep it derived from the same source as EXP_DAT above.

Parent: Add/Update NCR Counterpoint Gift Card FROM iPaaS.com.

Source: Lookup Translation — **CP Gift Card Activity ACTIV_TYP From iPaaS** · Destination: ACTIV_TYP

This is a recommended field. It records what happened to the card, and an activity that arrives without it says nothing about what it was. Counterpoint accepts the record without it and records I, meaning the card was issued, instead — so it should be mapped for accurate data. iPaaS.com describes the activity in words and Counterpoint stores a single-letter code, so this translation converts between them: issue, redeem, void, reinstate, and adjust each map to their Counterpoint equivalent.

The translation covers every activity type iPaaS.com can supply, so no activity should reach Counterpoint without a match. Subscribers should leave the rows in place: an activity whose type found no match supplies no code and is written without one, and each row's result should remain one of the codes Counterpoint permits, since a custom code produces an activity Counterpoint cannot interpret. Subscribers should validate the behavior in a staging environment before relying on it in production.

Source: Amount · Destination: AMT

This is a required field — NCR Counterpoint rejects the record without it, raising Amount(AMT) is a required field. It is the value of the individual activity, held to two decimal places. This is what was loaded, redeemed, or adjusted, not the card's remaining balance — the balance is carried by the CURR_AMT mapping on the parent collection, Add/Update NCR Counterpoint Gift Card FROM iPaaS.com. An activity arriving from iPaaS.com without an amount is rejected rather than transferred, so subscribers should confirm amounts are populated before enabling the collection.

Source: Location · Destination: STR_ID

This is a required field — NCR Counterpoint rejects the record without it, raising Store(STR_ID) is a required field. It is the store the activity is attributed to, stored as text of up to 10 characters; a longer value is shortened to fit rather than refused. Unlike the parent collection, which sets a fixed store, this mapping passes through whatever location the iPaaS.com activity carries — so the value arriving from iPaaS.com must be a store configured in the subscriber's own Counterpoint installation.

A value that is not a configured store is not refused. The transfer succeeds, and Counterpoint stores the activity against a store it does not recognise; the problem then surfaces later — when the activity is posted, or read by another Counterpoint function — rather than being reported as a transfer error you can trace back to the activity that caused it. Subscribers whose iPaaS.com locations do not correspond to Counterpoint store ids should replace this mapping with a translation or formula that converts between them, rather than leave activity attributed to stores their installation does not recognise. Subscribers or their MiSP should confirm that every location iPaaS.com can supply exists as a store in Counterpoint before enabling this collection. Subscribers should validate the behavior in a staging environment before relying on it in production.

Source: Timestamp · Destination: LST_MAINT_DT

This is an optional field. When the activity took place. Counterpoint records this against the activity row as its last-maintained date, so it also moves if the row is later amended in Counterpoint. Activity arriving without a timestamp is written without one.

Source: TransactionReferenceId · Destination: DOC_NO

This is an optional field. The document number the activity is associated with, stored as text of up to 15 characters. It is carried across for reference only — it does not create a link to a Counterpoint ticket, and activity that did not occur on a document arrives without one. Subscribers should treat it as a human-readable reference for tracing an activity back to a receipt, not as a relationship they can report against.

Source: SubstringAfterLastMatch(ExternalIdFromStructure(ExternalIds, SpaceportSystemId), "|") · Destination: SEQ_NO

This is a required field — NCR Counterpoint rejects the record without it, raising Sequence #(SEQ_NO) is a required field. It is also what stops the same activity being written to Counterpoint twice. The formula reads the reference iPaaS.com holds for an activity that has already been sent to Counterpoint and recovers the sequence number it was written under, so a repeat transfer updates that existing row rather than adding a duplicate one. Activity that has never been sent has no such reference, and is written as a new row.

Subscribers should not remap or remove this mapping. Without it, every transfer of a card would append its activity again, inflating the card's history and its balance in Counterpoint. Counterpoint does not accept a negative sequence number.

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.