NCR Counterpoint to iPaaS.com Sale Ticket Mapping Documentation

This mapping collection brings completed sale tickets from NCR Counterpoint into iPaaS.com. It carries the ticket's number, the system it originated in, its type and status, the email address the ticket is tied to, the header discount, tax, miscellaneous charges, subtotal and total, and the dates Counterpoint recorded against it. A ticket that iPaaS.com does not yet hold is added; a ticket it already holds is updated.

This family does not itself carry deletions. Where a separate Delete collection exists for this entity it handles removals from Counterpoint to iPaaS.com; otherwise a removal in Counterpoint is not propagated. See NCR Counterpoint Known Limitations.

Important: this collection reports sales that Counterpoint already holds, so subscribers whose sales originate in iPaaS.com and are written into Counterpoint through the sale ticket path above should adjust this collection as necessary rather than enabling it unchanged — a ticket this integration wrote into Counterpoint would otherwise be read straight back out and reported as a new sale. Subscribers or their MiSP should review this collection's mapping filter and its Add/Update settings before enabling it, and should define which system is the source of truth for a completed sale before running this collection alongside either of the collections named above.

Mapping Filter

Filter Description.

The filter is written across two lines. The first line must be removed before this collection transfers anything. That line is the whole of the first line shown above — the condition 1==0 && together with the comment that follows it, up to and including the comment. Because the condition it states can never be true, and the rest of the filter is joined to it, the whole filter evaluates to false for every record — the collection runs, selects nothing, and reports no error. A collection that appears to run cleanly while transferring nothing is the expected symptom of leaving that line in place.

Removing the first line leaves the working condition, which admits only records whose ticket type and document type are both T — completed sale tickets, as opposed to the orders, quotes, layaways, and holds Counterpoint keeps alongside them. Subscribers or their MiSP should review the remaining condition, and the Duplicate or Conflicting Collections guidance below, before removing that line.

Source: TKT_NO · Destination: TransactionNumber

This is a required field — iPaaS.com rejects the transaction without it. The sale ticket number as assigned in NCR Counterpoint, stored there as text of up to 15 characters and always populated. This is the value subscribers and their MiSP use to identify the ticket in both systems, and it is what iPaaS.com stores as the transaction's own number. Ticket numbers are assigned per station and drawer in Counterpoint rather than being unique across the whole company, so subscribers running multiple stores should confirm how their own numbering is configured before relying on this value alone to identify a ticket.

Source: SpaceportSystemId · Destination: SystemId

This is a required field — iPaaS.com rejects the transaction without it, and the value must be greater than zero. Records which connected system the transaction originated in, so that the ticket can be attributed back to its source. The value is supplied automatically by iPaaS.com for the subscription running the transfer — subscribers do not configure it and should not replace it with a fixed value, as a hardcoded or zero value causes the transfer to be rejected.

Source: Static value —Ticket` · Destination: Type

This is a required field — iPaaS.com rejects the transaction without it. Allowed values: Order, Shipment, Invoice, Hold, Quote, Ticket, Return, Validated Return, and Job. Every record this collection transfers is a completed Counterpoint sale ticket, so the value is fixed at Ticket rather than derived from the record. This is a genuine constant, not a value awaiting configuration. It pairs with the mapping filter: the filter admits only sale tickets, so a single static type is accurate for everything that passes it. Subscribers who widen the filter to admit other Counterpoint document types MUST replace this static with a formula that derives the matching type, because the type would otherwise be reported incorrectly for every record the widened filter lets through.

Source: Static value —Complete` · Destination: Status

This is a required field — iPaaS.com rejects the transaction without it. Allowed values: Pending, Complete, Cancelled, Shipped, Backorder, Refunded, Partially Refunded, Partially Shipped, Awaiting Pickup, Awaiting Payment, On Hold, Processing, Returned, and Draft. This collection reads Counterpoint's ticket history, which holds tickets that have already been rung out, so the value is fixed at Complete rather than derived from the record. This is a genuine constant, not a value awaiting configuration. Because the status is static, a ticket that is later voided or returned in Counterpoint does not report that change through this mapping — subscribers who need those states in iPaaS.com should confirm how their returns are recorded and map the status accordingly.

Source: (IsEmpty(BILL_EMAIL_ADRS_1)?"guest@theredrook.com":BILL_EMAIL_ADRS_1) · Destination: EmailAddress

This field is effectively required in this collection. iPaaS.com requires every transaction to be tied to a customer or a company, and satisfies that by requiring at least one of a customer id, a company id, or an email address — if none is supplied, the request is rejected. This collection maps none of the other two, so this mapping is the only thing tying the ticket to a customer, and the transfer fails if it resolves to nothing. That is why the formula never returns an empty result: it reads the billing email address from the ticket, and where the ticket has none, it substitutes a fallback address instead. Counterpoint stores the billing email as text of up to 50 characters and permits it to be empty, which is common on walk-in tickets rung out without customer details.

Placeholder value — replace during implementation: guest@theredrook.com is the address the integration ships with, and it is not a domain the subscriber owns. Every ticket that arrives without a billing email carries this same address into iPaaS.com. Subscribers or their MiSP MUST replace it with an address they control before the first transfer. Removing the fallback instead of replacing it is not a safe option — a ticket with no billing email would then resolve to an empty value and be rejected. Subscribers who would rather link tickets to customer records than to an email address should map the customer id field, which lifts the requirement from this mapping.

Source: SAL_TOT_HDR_DISC · Destination: DiscountAmount

This is an optional field. The total discount applied to the ticket as a whole in NCR Counterpoint, as opposed to discounts taken against individual lines, which the Add/Update NCR Counterpoint Sale Ticket Line TO iPaaS.com collection carries separately on each line. Counterpoint holds this to two decimal places and always supplies a value, reporting zero on tickets with no header discount. Subscribers reporting on total discount should account for both this figure and the line-level figures rather than either alone.

Source: SAL_TAX_AMT · Destination: TaxAmount

This is a recommended field. iPaaS.com accepts the transaction without it, but a ticket that reports a total without the tax that makes it up cannot be reconciled against the register, so it should be mapped for any meaningful sale ticket sync. The total tax charged on the ticket. Counterpoint holds this to two decimal places and always supplies a value, reporting zero on non-taxable tickets. This is the ticket-level total; the per-line allocation is carried separately by the EstimatedTaxAmount mapping on the Add/Update NCR Counterpoint Sale Ticket Line TO iPaaS.com collection, and the two are not guaranteed to sum identically because Counterpoint allocates rounded amounts across lines.

Source: SAL_TOT_MISC · Destination: ShippingAmount

This is an optional field. Carries Counterpoint's total miscellaneous charges on the ticket into the shipping amount in iPaaS.com. Subscribers should note that Counterpoint's miscellaneous charge total is not exclusively a shipping figure — it accumulates whatever miscellaneous charges a site has configured, which may include delivery, handling, or unrelated fees. Where a site uses miscellaneous charges for anything besides shipping, this value overstates shipping in iPaaS.com. Subscribers who need shipping reported precisely should confirm what their own miscellaneous charges represent and replace this mapping with a formula that isolates the shipping component.

Source: SAL_SUB_TOT · Destination: Subtotal

This is a recommended field. iPaaS.com accepts the transaction without it, but the subtotal is what separates merchandise value from tax and charges, so it should be mapped for any meaningful sale ticket sync. The ticket's merchandise total before tax and miscellaneous charges, as calculated by Counterpoint. Counterpoint holds this to two decimal places and always supplies a value. This is a point-in-time figure recorded when the ticket was rung out; it is not recalculated by iPaaS.com from the transferred lines, so subscribers reconciling it against the sum of line extended prices should expect rounding and header-discount differences.

Source: SAL_TOT · Destination: Total

This is a recommended field. iPaaS.com accepts the transaction without it, but a sale ticket with no total records that a sale happened without recording its value, so it should be mapped for any meaningful sale ticket sync. The final amount of the ticket including tax and charges, as calculated by Counterpoint. Counterpoint holds this to two decimal places and always supplies a value. This is the figure subscribers should reconcile against the payments carried by the Add/Update NCR Counterpoint Sale Ticket Payment TO iPaaS.com collection, which should sum to it on a fully paid ticket.

Source: TKT_DT · Destination: TransactionCreatedDateTime

This is a recommended field. iPaaS.com accepts the transaction without it, but sales are only meaningful in sequence and date-based reporting depends on it, so it should be mapped for any meaningful sale ticket sync. The date Counterpoint recorded against the ticket. This is the ticket's own business date rather than the moment the transfer ran, so back-dated tickets arrive with their Counterpoint date intact. Subscribers should confirm whether their sites record this as a date alone or a full timestamp before reporting on time of day.

Source: LST_MAINT_DT · Destination: TransactionUpdatedDateTime

This is an optional field. Counterpoint's last-maintained date for the ticket, carried across so subscribers can see when the record last changed. Because this collection updates as well as adds, this value is what distinguishes a ticket that has been amended since its last transfer from one that has not. For tickets written once and never amended it stays at the original write; for rows later corrected, it moves to the correction. It reflects the last time the row changed in Counterpoint, not the last time it transferred to iPaaS.com, so subscribers should not read it as a sync timestamp.

Parent: Add/Update NCR Counterpoint Sale Ticket TO iPaaS.com.

Source: Static value —Product` · Destination: Type

This is a required field — iPaaS.com rejects the line without it. Allowed values: Product and Giftcard. The value is fixed at Product for every line this collection transfers rather than derived from the record. This is a genuine constant, not a value awaiting configuration.

Subscribers should understand what the fixed value means for gift cards sold on a ticket. Counterpoint records a gift card sale as a line on the ticket like any other item, and this mapping types that line as Product rather than Giftcard. Two consequences follow. First, iPaaS.com requires a line typed Giftcard to carry the gift card's id alongside it, and this collection carries no such value — so typing these lines as Giftcard without also supplying that id would cause them to be rejected. Second, iPaaS.com requires the Sku on a line typed Product to resolve to a product that already exists in iPaaS.com. Where a site's gift card item exists as a normal Counterpoint item and transfers through the product collections, that requirement is met and the line transfers as an ordinary product line. Where it does not, the line is rejected — see the Sku mapping below. Subscribers selling gift cards through Counterpoint should confirm this behavior against their own data before relying on gift card sales being distinguishable from merchandise sales in iPaaS.com.

Source: SEQ_NO · Destination: SequenceNumber

This is a recommended field. iPaaS.com accepts the line without it, but the lines of a ticket are only meaningful in the order they were rung in, so it should be mapped for any meaningful sale ticket sync. The line's position on the ticket as recorded in Counterpoint, carried across as a whole number so that lines appear in iPaaS.com in the order they appear on the receipt. Counterpoint always supplies a value.

Source: Static value —Complete` · Destination: Status

This is a required field — iPaaS.com rejects the line without it. Allowed values are the same set the parent transaction's status accepts: Pending, Complete, Cancelled, Shipped, Backorder, Refunded, Partially Refunded, Partially Shipped, Awaiting Pickup, Awaiting Payment, On Hold, Processing, Returned, and Draft. This collection reads lines from tickets that have already been rung out, so the value is fixed at Complete rather than derived from the record. This is a genuine constant, not a value awaiting configuration. It matches the static status set on the parent collection, so a ticket and its lines report the same state.

Source: ITEM_NO · Destination: Sku

This field is effectively required in this collection. iPaaS.com does not require a sku on every line in general, but it does require that any sku on a line whose type is Product resolves to a product or variant that already exists in iPaaS.com — and the Type mapping on this collection is statically set to Product for every line it transfers. A line that arrives with no sku, or with one that resolves to nothing, is rejected. The Counterpoint item number for the line. Counterpoint stores this as text of up to 20 characters and always populates it.

This mapping carries a hard prerequisite. iPaaS.com requires the sku on a line whose type is Product to resolve to a product or variant that already exists in iPaaS.com. Because the Type mapping on this collection is statically set to Product, that requirement applies to every line this collection transfers, without exception. A line whose item number does not match an existing iPaaS.com product or variant is rejected rather than transferred without a product link.

This means the products a subscriber sells MUST already exist in iPaaS.com before the first sale ticket transfers. Transferring a sale ticket does not pull its products across on its own. Subscribers or their MiSP MUST do one of the following before enabling this collection: EITHER (a) run the NCR Counterpoint product collections to completion first, so that every item that can appear on a ticket exists in iPaaS.com, OR (b) confirm that products are already present in iPaaS.com from another source and that their skus match the Counterpoint item numbers exactly. One of the two MUST be done at install time. Subscribers should also account for items that are retired in Counterpoint but still present on historical tickets, and for any gift card item, which reaches this mapping as an ordinary sku for the reasons set out under Type above.

Source: DESCR · Destination: Description

This is an optional field. The line description as recorded on the ticket in NCR Counterpoint, carried across unchanged for reference and reporting. Counterpoint stores this as text of up to 50 characters and permits it to be empty. This is the description captured on the ticket at the time of sale rather than the product's current description, so it continues to reflect what the receipt said even after the product is renamed in either system. Subscribers replacing this mapping with a formula are not held to the 50-character limit by iPaaS.com, but should keep results short enough to stay readable alongside descriptions that came straight from Counterpoint.

Source: QTY_SOLD · Destination: Qty

This is a recommended field. iPaaS.com accepts the line without it, but a line with no quantity records what was sold without recording how much of it, so it should be mapped for any meaningful sale ticket sync. The quantity sold on the line. Counterpoint always supplies a value and holds it to four decimal places, which supports items sold by weight or measure as well as by unit. Quantities are transferred with the sign Counterpoint records them with, and Counterpoint permits negative quantities on a line, so subscribers should not assume every quantity is positive without confirming against their own data.

Source: EXT_PRC · Destination: ExtendedPrice

This is a recommended field. iPaaS.com accepts the line without it, but the extended price is what the line contributes to the ticket, so it should be mapped for any meaningful sale ticket sync. The total price for the line as calculated by Counterpoint — quantity multiplied by the price actually charged. Counterpoint always supplies a value and holds it to two decimal places. This is the figure already reduced by any line discount, whereas OriginalUnitPrice reports the price before discounting. It is a point-in-time value recorded when the ticket was rung out and is not recalculated by iPaaS.com from the other mapped fields.

Source: PRC_1 · Destination: OriginalUnitPrice

This is an optional field. The item's base unit price in Counterpoint, carried across so that the price before any discount can be compared against what was actually charged. Together with DiscountAmount and ExtendedPrice it lets a subscriber report what a line was marked down from without needing the pricing rules that produced it. Counterpoint sites can configure more than one price level for an item, and this mapping carries the first of them; subscribers whose sites sell from a different price level should confirm which level their tickets are priced from before reporting against this value.

Source: LIN_DISC_AMT · Destination: DiscountAmount

This is an optional field. The discount taken against this individual line in Counterpoint, as opposed to a discount applied to the ticket as a whole, which the parent collection Add/Update NCR Counterpoint Sale Ticket TO iPaaS.com carries separately in its own DiscountAmount mapping. Subscribers reporting on total discount should account for both the line-level figures and the ticket-level figure rather than either alone.

Source: TAX_AMT_ALLOC · Destination: EstimatedTaxAmount

This is an optional field. The share of the ticket's tax that Counterpoint allocated to this line. Counterpoint always supplies a value and holds it to two decimal places, reporting zero on non-taxable lines. This is an allocation rather than an independently calculated figure, which is why iPaaS.com records it as an estimate: Counterpoint calculates tax at the ticket level and distributes rounded amounts across the lines. Subscribers should expect the line allocations to differ slightly from a per-line recalculation, and should report the ticket's total tax from the TaxAmount mapping on the parent collection rather than by summing this field.

Source: EXT_WEIGHT · Destination: Weight

This is an optional field. The weight Counterpoint recorded for the line. This is the extended weight — the weight for the whole quantity on the line, not the weight of a single unit — so subscribers who need per-unit weight should divide by Qty rather than reading this value directly. The unit of measure is whatever the subscriber's Counterpoint site is configured to use; it is not carried across by this mapping and is not converted by iPaaS.com. Items configured without a weight in Counterpoint transfer with zero here, which is not distinguishable from a genuine zero weight.

Parent: Add/Update NCR Counterpoint Sale Ticket TO iPaaS.com.

Source: PAY_COD · Destination: Method

This is a required field — iPaaS.com rejects the payment without it. The pay code Counterpoint recorded the payment against, such as the site's code for cash, cheque, or a card type. Counterpoint stores this as text of up to 10 characters and permits it to be empty.

This mapping carries a hard prerequisite. iPaaS.com requires the method to match the name of a Payment Method that is already configured in iPaaS.com. A payment whose value does not match a configured Payment Method by name is rejected rather than transferred without one. Two things about this deserve attention. First, the match is against the Payment Method's name in iPaaS.com, while Counterpoint supplies its pay code — these are not the same thing, and a site whose cash pay code is CASH needs a Payment Method named CASH, not one named Cash Payment. Second, Counterpoint permits the pay code to be empty, and an empty value cannot match any configured Payment Method, so such a payment is rejected.

Subscribers or their MiSP MUST do one of the following before the first transfer: EITHER (a) configure a Payment Method in iPaaS.com whose name exactly matches each pay code in use in Counterpoint, OR (b) replace this mapping with a lookup translation or formula that converts each Counterpoint pay code into the name of an already-configured Payment Method. One of the two MUST be done at install time. Subscribers should enumerate every pay code their sites can produce, including codes used only rarely or only at some stores, because a single unmatched code fails the payment.

Subscribers should also confirm this behavior for gift cards specifically. Where a payment is taken against a Payment Method whose type in iPaaS.com is Gift Card, iPaaS.com additionally requires the gift card's id to be supplied alongside the payment, and this collection carries no such value. Subscribers who accept gift cards as tender in Counterpoint should validate in a staging environment whether those payments transfer before relying on them in production.

Source: DESCR · Destination: Description

This is an optional field. The payment description as recorded on the ticket in NCR Counterpoint, carried across unchanged for reference. Counterpoint stores this as text of up to 30 characters and permits it to be empty. Unlike Method, this value is not matched against anything in iPaaS.com and carries no configuration requirement — it is free text for subscribers reading the payment back. Subscribers replacing this mapping with a formula are not held to the 30-character limit by iPaaS.com.

Source: AMT · Destination: Amount

This is a recommended field. iPaaS.com accepts the payment without it, but a payment with no amount records that the ticket was tendered without recording for how much, so it should be mapped for any meaningful sale ticket sync. The value of this individual payment — not the ticket's total, which the parent collection Add/Update NCR Counterpoint Sale Ticket TO iPaaS.com carries in its Total mapping. A ticket settled across more than one tender produces one record per payment, and on a fully paid ticket those amounts should sum to the ticket total. Counterpoint always supplies a value and holds it to two decimal places. Amounts are transferred with the sign Counterpoint records them with, so subscribers should not assume every payment is positive without confirming against their own data.

Source: Static value —Captured` · Destination: Status

This is an optional field. Unlike the status on the parent transaction and on its lines, iPaaS.com neither requires a payment status nor documents a set of allowed values for it, so this value is not checked against a list. The value is fixed at Captured for every payment this collection transfers rather than derived from the record. This is a genuine constant, not a value awaiting configuration. It is accurate for what this collection carries: these payments come from tickets that have already been rung out and settled, so the money has been taken rather than merely authorized. Because the status is static, a payment later voided or refunded in Counterpoint does not report that change through this mapping.

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.