iPaaS.com to NCR Counterpoint Order Mapping Documentation

This mapping collection writes orders from iPaaS.com into NCR Counterpoint. Each iPaaS.com transaction that passes the mapping filter becomes an open Counterpoint order document — an order to be filled, rather than a completed sale at the till. The collection carries the order's ticket number, the store, station and drawer it is attributed to, its billing and shipping addresses, its totals and its tax, and the link back to the Counterpoint customer the order belongs to.

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.

In plain language, an iPaaS.com transaction reaches this collection only when all of the following hold:

The -D and -GC suffixes are how the integration keeps one source order that produced several kinds of Counterpoint document from being written more than once. Subscribers whose source system already uses those suffixes on transaction numbers for an unrelated purpose should expect those transactions to be skipped, and should review this filter before enabling the collection.

Source: "BC" + TransactionNumber · Destination: TKT_NO

This is a required field — NCR Counterpoint rejects the record without it. The ticket number is how the order is identified. The formula takes the iPaaS.com transaction number and places a two-character prefix in front of it, so that orders arriving from iPaaS.com are distinguishable from tickets created at the point of sale and cannot collide with them.

Placeholder value — replace during implementation: "BC" is an example prefix, not a Counterpoint default. It stands for BigCommerce — the default template was authored for a Counterpoint and BigCommerce pairing — so subscribers on any other source system will find every Counterpoint ticket number prefixed BC. Replace it with a prefix identifying your own source system before enabling this collection. Keep the replacement at two characters; the rest of the ticket number is sized on the assumption of a two-character prefix.

Source: "Z" · Destination: USR_ID

This is a recommended field. The Counterpoint point-of-sale user recorded as having entered the order. Counterpoint accepts the record without it and creates the order with no user recorded against it, so it should be mapped for accurate data. Every order transferred by this collection is attributed to whichever single user is set here, so this value determines who appears as the order taker in Counterpoint reporting.

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

Placeholder value — replace during implementation: "Z" is an example user id, not a Counterpoint default. Replace it with a user id from your own Counterpoint installation before enabling this collection — a user id your installation does not have is stored rather than refused, and surfaces as a problem later rather than as a transfer error. Subscribers who would rather not attribute web orders to a real employee should create a dedicated user for the purpose and use that id here.

Source: "MAIN" · Destination: STR_ID

This is a required field — NCR Counterpoint rejects the record without it. The store the order is created in. A value must be present, and it must be a store configured in your own Counterpoint installation.

Only presence is checked during the transfer, not the value. A store id your installation does not have is accepted and stored on the order rather than being reported as a transfer error, and it then fails later — when the order is posted or used by another Counterpoint function — rather than at the point of transfer. Subscribers or their MiSP should confirm the store exists in Counterpoint before enabling this collection.

Placeholder value — replace during implementation: "MAIN" is an example store id, not a Counterpoint default. Replace it with the id of the store the orders should be created in within your own Counterpoint installation, and do so before enabling this collection — a store id that installation does not have is stored rather than refused, and surfaces later rather than as a transfer error. Orders 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 order is created in. As with STR_ID above, a value must be present, and it must be a station configured in your own Counterpoint installation. Together with STR_ID and DRW_ID, this places the order at a specific till within a specific store.

Only presence is checked during the transfer, not the value. A station id your installation does not have is accepted and stored on the order rather than being reported as a transfer error, and it then fails later — when the order is posted or used by another Counterpoint function — rather than at the point of transfer. Subscribers or their MiSP should confirm the station exists in Counterpoint before enabling this collection.

Placeholder value — replace during implementation: "1" is an example station id, not a Counterpoint default. Replace it with a station id from your own Counterpoint installation before enabling this collection. A single character does not make this a fixed constant — it is an identifier that varies by installation, and one your installation does not have is stored rather than refused.

Source: "1" · Destination: DRW_ID

This is a recommended field. The drawer the order is created in, within the station set by STA_ID. Counterpoint accepts the record without it and creates the order with no drawer recorded against it, so it should be mapped for accurate data.

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

Placeholder value — replace during implementation: "1" is an example drawer id, not a Counterpoint default. Replace it with a drawer id from your own Counterpoint installation before enabling this collection. As with the station id, a single character does not make this a fixed constant, and a drawer id that installation does not have is stored rather than refused.

Source: "WEBSITE" · Destination: TAX_EXEMPT_NO

This is a recommended field. Counterpoint accepts the record without it. Because this collection overrides the tax amount rather than letting Counterpoint calculate it — see ORD_HAS_TAX_OVRD below — the exemption number recorded here is what identifies an order on which no tax was charged, so it should be mapped for accurate data. Counterpoint does not constrain the format or the contents of this value, so a fixed value serves the purpose.

Placeholder value — replace during implementation: "WEBSITE" is an example value, not a Counterpoint default. Replace it with a value meaningful in your own Counterpoint installation before enabling this collection, so that tax-exempt web orders are identifiable in Counterpoint reporting.

Source: "WEBSITE" · Destination: TAX_OVRD_REAS

This is a recommended field. Counterpoint accepts the record without it. Because this collection sets a tax override on every order, the reason code recorded here is what explains that override to anyone reading the order in Counterpoint, so it should be mapped for accurate data.

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

Placeholder value — replace during implementation: "WEBSITE" is an example reason code, not a Counterpoint default. Replace it with a tax override reason code configured in your own Counterpoint installation before enabling this collection. Reason codes are configured per installation, so the value that works in a demonstration company will not necessarily be one your installation knows — and one it does not know is stored rather than refused.

Source: ((TaxAmount > 0) && (Coalesce((string)(FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "Region")),(string)(FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "Region"))) == "Tennessee") ? "MEMTN" : (((TaxAmount > 0) && !(Coalesce((string)(FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "Region")),(string)(FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "Region"))) == "Tennessee") ? "MEMTN" : "MEMTN"))) · Destination: TAX_COD

This is a recommended field, and it is required in practice for accurate tax reporting. The tax code recorded on the order. Counterpoint accepts the record without it and creates the order with no tax code, so it should be mapped.

Whatever value is supplied must be a tax code configured in your own Counterpoint installation. Nothing checks that during the transfer. A tax code your installation does not have is accepted by the transfer and stored on the order rather than being reported as a transfer error, and it then fails later — when the order is posted, or when another Counterpoint function uses it — rather than at the point of transfer. That makes an unconfigured tax code silent at the moment it is introduced and visible only afterwards, some distance from the order that carried it. Subscribers or their MiSP should confirm the tax code exists in Counterpoint before enabling this collection.

The formula is written as a decision between three tax situations: a taxed order shipping to a nominated home state, a taxed order shipping anywhere else, and an untaxed order. It reads the state from the primary shipping address, falls back to the primary billing address when the order has no shipping address, and compares it against a state named in the formula.

Subscribers should be aware that in the template as shipped, all three branches return the same tax code, so the decision has no effect until the formula is edited — every order receives the one code regardless of destination or tax amount. The structure is there to be filled in, not to be relied on as-is.

Placeholder value — replace during implementation: the state name and the tax code in this formula are example values, not Counterpoint defaults. They name a single US state and a tax code from a demonstration company. Replace both with the state and the tax codes configured in your own Counterpoint installation before enabling this collection, and give each branch the code that belongs to it — a code your installation does not have is stored rather than refused, and surfaces later rather than as a transfer error. Subscribers who do not need state-by-state tax codes should replace the formula with the single code their installation uses.

Source: SumHeaderDiscounts(Discounts) · Destination: ORD_TOT_HDR_DISC

This is an optional field, and it applies only to orders carrying header-level discounts. The total header discount applied to the order. Source systems commonly allow several discounts on one order, while Counterpoint records a single header discount, so the formula adds the iPaaS.com header discounts together and supplies the total. An order with no header discounts produces nothing here.

The header discount amount is added back into the order's gross subtotal and total during the transfer. This means the source system must already have allocated the discount into each line's extended price for the resulting order to balance. Subscribers whose source supplies only an order-level discount, with no per-line allocation, need to allocate it across the lines with a formula on the iPaaS.com side before the order reaches this collection.

This mapping works alongside Add NCR Counterpoint Order Header Discount Totals FROM iPaaS.com, which writes the discount record itself.

Source: TaxAmount · Destination: ORD_TAX_AMT

This is a required field — NCR Counterpoint rejects the record without it. The total tax on the order. Because this collection overrides Counterpoint's own tax calculation — see ORD_HAS_TAX_OVRD below — the amount supplied here is the amount Counterpoint uses, rather than one Counterpoint works out for itself. An order that reaches this collection with no tax amount at all is rejected rather than having tax calculated for it, so subscribers whose source can produce orders with no tax amount should supply a zero rather than leave the value empty.

Source: ShippingAmount · Destination: ORD_MISC_AMT_1

This is a required field — NCR Counterpoint rejects the record without it, with the error Misc charge 1(ORD_MISC_AMT_1) is a required field. The shipping charge on the order, recorded in the first of Counterpoint's miscellaneous amount fields. Subscribers already using that field for another purpose can record their shipping charge in one of the other miscellaneous amount fields instead, but a value must still reach this one; subscribers who do not charge shipping should supply a zero rather than leave it unmapped.

Source: Subtotal · Destination: ORD_SUB_TOT

This is a required field — NCR Counterpoint rejects the record without it. The order subtotal is recalculated from the order lines during the transfer, so the value mapped here does not decide what Counterpoint stores, but a value must be present for the record to be accepted at all. Subscribers who find the Counterpoint subtotal does not match the source order should look to the line values and to any discount allocation rather than to this mapping.

Source: Total · Destination: ORD_TOT

This is a required field — NCR Counterpoint rejects the record without it. As with ORD_SUB_TOT above, the order total is recalculated during the transfer, so the value mapped here does not decide what Counterpoint stores, but a value must be present for the record to be accepted at all.

Source: "O" · Destination: DOC_TYP

This is a recommended field. Marks the document Counterpoint creates as an order rather than a completed sale. Counterpoint accepts the record without it and records T instead, which produces a ticket rather than an order, so it should be mapped for accurate data. This is a genuine Counterpoint constant rather than an example, and it is what makes this collection produce orders. Changing it changes what kind of document every transfer creates, so it should be left as it is. Subscribers who want completed sale tickets instead of orders should use Add NCR Counterpoint Sale Ticket FROM iPaaS.com rather than alter this value.

Source: CustomerFromEmail(EmailAddress) · Destination: CUST_NO

This is an optional field. Links the order to a Counterpoint customer by searching Counterpoint for a customer whose email address matches the one on the iPaaS.com order. Where several Counterpoint customers share the address, a customer flagged as an ecommerce customer is preferred; where none is flagged, the first match is used.

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

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

This mapping searches for a customer; it does not create one. Subscribers who want their web customers linked to real Counterpoint customer records should transfer customers to Counterpoint with Add/Update NCR Counterpoint Customer FROM iPaaS.com before orders arrive. Matching is by email address alone, so customers who order under an address that differs from the one held in Counterpoint will not be linked.

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

This is an optional field. The shipping method, taken from the primary shipping address on the iPaaS.com order. An order with no primary shipping address, or one whose shipping address carries no shipping method, produces nothing here and the order is created without a shipping method.

Whatever value is written must be a ship-via code configured in your own Counterpoint installation, and the value written is whatever the source system holds as the shipping method — which will not necessarily be worded the way your Counterpoint installation words it. Nothing checks that during the transfer. A shipping method the installation does not have as a ship-via code is accepted and stored on the order rather than being reported as a transfer error, and it then fails later — when the order is posted or used by another Counterpoint function — rather than at the point of transfer. This makes an unmatched shipping method easy to miss, because the orders carrying it transfer successfully. Subscribers should confirm that the values arriving from the source correspond to ship-via codes their own Counterpoint installation recognises, and add a Lookup Translation to this mapping where they do not. The sibling collection Add/Update NCR Counterpoint Shipping Method TO iPaaS.com brings Counterpoint's own shipping method codes into iPaaS.com and is a useful reference when building that translation.

Source: "0" · Destination: TIMES_PRTD

This is a recommended field. It counts how many times the ticket has been printed, and zero is the standard starting value for a ticket that has not yet been printed. Counterpoint accepts the record without it and records 0 instead, which is the same value this mapping supplies. This is a genuine Counterpoint constant rather than an example, so it does not need changing for a typical install.

Source: "A" · Destination: ORD_HAS_TAX_OVRD

This is a recommended field, and it is a control mapping rather than a value. It tells Counterpoint that the order carries a tax override and that the override is expressed as an amount rather than as a percentage. Counterpoint accepts the record without it and records ! — no override — instead, which hands tax calculation back to Counterpoint, so it should be mapped for accurate data. This is what stops Counterpoint recalculating tax on the order and makes it accept the figure supplied by ORD_TAX_AMT above, which is the behavior subscribers want when the source system has already calculated tax at checkout.

This is a genuine Counterpoint constant rather than an example. Removing or changing it hands tax calculation back to Counterpoint, which will usually disagree with the tax the customer was charged at checkout. It also gives the tax mappings around it their purpose: TAX_EXEMPT_NO and TAX_OVRD_REAS are recommended because of this override.

Source: "O" · Destination: DOC_STAT

This is a recommended field. Sets the document status to open, which is correct for an order that has not yet been filled. Counterpoint accepts the record without it and records O — open — instead, which is the same value this mapping supplies. This is a genuine Counterpoint constant rather than an example. Orders are moved on from open by the sibling collections Update NCR Counterpoint Order Complete FROM iPaaS.com and Update NCR Counterpoint Order Cancel FROM iPaaS.com rather than by changing this value.

Source: Truncate((FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "Company") == "" ? (FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "FirstName") + " " + FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "LastName")) : (FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "Company"))),40) · Destination: BILL_NAM

This is a recommended field. The bill-to name shown on the ticket. Where the primary billing address carries a company, the company is used; otherwise the first and last names are joined with a space. This mirrors the way Counterpoint itself decides a bill-to name from its own name-type setting, and it is kept consistent with BILL_NAM_TYP below, which records which of the two was used.

The result is trimmed to 40 characters. Subscribers replacing this mapping should keep a trim in place — Counterpoint allocates limited space for this field, and a longer name would not fit as-is.

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

This is a recommended field. The first name from the primary billing address, trimmed to 15 characters to fit the space Counterpoint allocates. Subscribers replacing this mapping should keep the trim in place. Longer first names are shortened rather than rejected, so subscribers with long names in their source data should expect them to be cut at 15 characters here.

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

This is a recommended field. The last name from the primary billing address, trimmed to 25 characters to fit the space Counterpoint allocates. Subscribers replacing this mapping should keep the trim in place.

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

This is an optional field. The second line of the primary billing address, trimmed to 40 characters to fit the space Counterpoint allocates. Orders whose billing address has only one line produce nothing here.

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

This is an optional field. The third line of the primary billing address, trimmed to 40 characters to fit the space Counterpoint allocates. Most source systems supply at most two address lines, so this is commonly empty.

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

This is a recommended field. The city from the primary billing address, trimmed to 20 characters to fit the space Counterpoint allocates. Subscribers replacing this mapping should keep the trim in place.

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

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

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

This is an optional field. The country from the primary billing address, trimmed to 20 characters to fit the space Counterpoint allocates. The value written is whatever the source system holds, so subscribers whose source supplies country codes where Counterpoint expects country names, or the reverse, should add a Lookup Translation to this mapping.

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

This is a recommended field, and it is a control mapping rather than a value. It records whether the bill-to name is a person or a business, which tells Counterpoint how to interpret BILL_NAM above. Where the primary billing address carries a company the order is marked as a business; otherwise it is marked as a person. Counterpoint accepts the record without it and records B — business — instead, which is wrong for the consumer orders that make up most of what this collection carries, so it should be mapped for accurate data.

This mapping is derived from the same source as BILL_NAM, and the two need to stay consistent: an order marked as a business but carrying a person's name, or the reverse, produces a Counterpoint record whose name handling does not match its data. Subscribers replacing either mapping should replace both together.

Source: Truncate((FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "Company") == "" ? (FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "FirstName") + " " + FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "LastName")) : (FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "Company"))),40) · Destination: SHIP_NAM

This is a recommended field. The ship-to name shown on the ticket, trimmed to 40 characters to fit the space Counterpoint allocates.

Whether the ship-to name is a person or a business is decided from the primary shipping address: where it carries no company, the shipping first and last names are joined and used; where it does carry one, a company name is used. It works as a pair with the SHIP_NAM_TYP mapping, which records which of the two was chosen, and both decide it from the same test.

One detail is worth knowing before relying on this field for business orders: on the company branch the value is read from the primary billing address rather than the shipping address. For a customer whose billing and shipping company are the same — the usual case — the two are identical and the distinction does not arise. Where they differ, or where there is a shipping company but no billing company, the ship-to name follows the billing address. Subscribers or their MiSP who ship to companies other than the one being billed should confirm the ship-to name is what they want before enabling this collection, and can point the mapping at the shipping address instead if they need it to follow the shipment.

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

This is a recommended field. The first name from the primary shipping address, trimmed to 15 characters to fit the space Counterpoint allocates. Orders with no primary shipping address produce nothing here.

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

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

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

This is an optional field. The second line of the primary shipping address, trimmed to 40 characters to fit the space Counterpoint allocates.

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

This is an optional field. The third line of the primary shipping address, trimmed to 40 characters to fit the space Counterpoint allocates. Most source systems supply at most two address lines, so this is commonly empty.

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

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

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

This is a recommended field. The postal code from the primary shipping address, trimmed to 15 characters to fit the space Counterpoint allocates. Subscribers using Counterpoint's own tax calculation elsewhere should note that this collection overrides tax rather than calculating it, so this value does not drive the tax on the order.

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

This is an optional field. The country from the primary shipping address, trimmed to 20 characters to fit the space Counterpoint allocates. As with BILL_CNTRY above, the value written is whatever the source system holds, so subscribers whose source and Counterpoint express countries differently should add a Lookup Translation to this mapping.

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

This is a recommended field, and it is a control mapping rather than a value. It records whether the ship-to name is a person or a business, which tells Counterpoint how to interpret SHIP_NAM above. Where the primary shipping address carries a company the order is marked as a business; otherwise it is marked as a person. As with BILL_NAM_TYP above, Counterpoint accepts the record without it and records B — business — instead, so it should be mapped for accurate data.

Unlike SHIP_NAM, this mapping reads the company from the shipping address in both branches. Subscribers replacing SHIP_NAM should keep the two consistent with each other.

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

This is a recommended field. The state or region from the primary billing address, trimmed to 10 characters to fit the space Counterpoint allocates. Ten characters is short enough to matter: a source system supplying full state names rather than abbreviations will have longer names cut short here, so subscribers in that position should convert to abbreviations with a Lookup Translation rather than relying on the trim.

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

This is a recommended field. The state or region from the primary shipping address, trimmed to 10 characters to fit the space Counterpoint allocates. As with BILL_STATE above, subscribers whose source supplies full state names should convert to abbreviations rather than relying on the trim.

Subscribers editing the TAX_COD formula above should note that it compares against the full state name as the source system supplies it, before this trim is applied — the two read the same source field but are not otherwise connected.

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

This is a recommended field. The first line of the primary billing address, trimmed to 40 characters to fit the space Counterpoint allocates. Subscribers replacing this mapping should keep the trim in place.

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

This is a recommended field. The first line of the primary shipping address, trimmed to 40 characters to fit the space Counterpoint allocates. Orders with no primary shipping address produce nothing here, which is normal for orders collected in store rather than shipped.

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

This is a recommended field. The email address from the iPaaS.com order, trimmed to 50 characters to fit the space Counterpoint allocates. This is the order's own email address rather than one read from an address record, and it is the same value CUST_NO above uses to find a Counterpoint customer — so an order that could not be matched to a customer still carries the address it was placed under, which is what subscribers need in order to reconcile it by hand.

Parent: Add NCR Counterpoint Order FROM iPaaS.com.

Source: LocalDateTimeFromDateTimeOffset(NoteCreatedDateTime) · Destination: NOTE_DAT

This is a recommended field. The date and time the note was written. iPaaS.com holds the moment together with its offset from universal time, while Counterpoint records a plain local date and time, so the formula converts one to the other rather than passing the value straight through. A note arriving without a created date produces nothing here.

Subscribers replacing this mapping should keep the conversion in place. Supplying the raw iPaaS.com value would leave Counterpoint recording a time that is right for the source system's time zone but wrong for the store's.

Source: SequenceNumber · Destination: NOTE_SEQ_NO

This is a required field — NCR Counterpoint rejects the record without it. The position of the note among the order's notes, carried straight from the iPaaS.com note. Together with the order it belongs to, this is what identifies the note in Counterpoint, so two notes on the same order need different sequence numbers.

This collection and Add NCR Counterpoint Order Staff Note FROM iPaaS.com both write notes to the same order and both take their sequence number from the source note. Subscribers running both should confirm that the notes arriving from their source system carry sequence numbers that do not collide across the two.

Source: Type · Destination: NOTE_ID

This is a required field — NCR Counterpoint rejects the record without it. The note identifier, carried from the iPaaS.com note's type. This is what tells Counterpoint what kind of note it is holding, and it is what distinguishes a note written for the customer from one written for staff once both are on the order.

The value written is whatever the source system holds as the note type, which will not necessarily be worded the way your Counterpoint installation words it. Subscribers should confirm that the note types arriving from the source correspond to note identifiers their own Counterpoint installation recognises, and add a Lookup Translation to this mapping where they do not. Subscribers running this collection alongside Add NCR Counterpoint Order Staff Note FROM iPaaS.com should give the two kinds of note distinct identifiers, since the note identifier is what separates them in Counterpoint.

Source: Text · Destination: NOTE_TXT

This is a recommended field. The body of the note, carried straight from the iPaaS.com note. This is the note's whole content — Counterpoint accepts the note without it, but what arrives is an empty note, so it should be mapped for accurate data. Because a customer note is text the customer wrote, subscribers should validate how their own Counterpoint installation handles long or formatted note text in a staging environment before relying on it in production, since source systems commonly allow markup and line breaks that a Counterpoint note is not intended to carry.

Parent: Add NCR Counterpoint Order FROM iPaaS.com.

Mapping Filter

Filter Description.

Only lines that are not gift card lines are written to Counterpoint. Gift card lines are not supported on orders — Counterpoint records the sale of a gift card differently from the sale of stock — so a line selling a gift card is skipped here. Subscribers selling gift cards should use Add/Update NCR Counterpoint Gift Card FROM iPaaS.com and the deposit ticket collections rather than expect gift cards to transfer as order lines. Note that the parent collection, Add NCR Counterpoint Order FROM iPaaS.com, already skips orders whose entire content is the sale of gift cards, so this filter catches the mixed order — one carrying both stock and a gift card.

Source: "WEBSITE" · Destination: PRC_OVRD_REAS

This is a recommended field. Counterpoint accepts the line without it. Because every line is flagged as having a price override — see HAS_PRC_OVRD below — the reason code recorded here is what explains that override to anyone reading the order in Counterpoint, so it should be mapped for accurate data.

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

Placeholder value — replace during implementation: "WEBSITE" is an example reason code, not a Counterpoint default. Replace it with a price override reason code configured in your own Counterpoint installation before enabling this collection. Reason codes are configured per installation, so the value that works in a demonstration company will not necessarily be one your installation knows — and one it does not know is stored rather than refused.

Source: SequenceNumber · Destination: SEQ_NO

This is a required field — NCR Counterpoint rejects the record without it. The position of the line on the order, carried straight from the iPaaS.com line's sequence number. This is what keeps the Counterpoint lines in the same order as the source order, and what distinguishes two lines that are otherwise identical.

Source: Qty · Destination: QTY_SOLD

This is a recommended field. The quantity ordered, carried straight from the iPaaS.com line. Counterpoint accepts the line without it and records 1 instead, so it should be mapped for accurate data. This quantity is expressed in the unit set by QTY_UNIT below, so the two need to agree: a quantity of six recorded against a six-pack unit is six six-packs, not six singles.

Source: QtyShipped · Destination: QTY_SHIPPED

This is a recommended field. The quantity already shipped against the line. Counterpoint accepts the line without it and records 0 instead. Because this collection creates orders rather than completed sales, that is normally the right answer at the point the order is transferred, and Counterpoint fills the field as the order is filled. Subscribers whose source system ships before the order reaches Counterpoint should confirm the resulting Counterpoint orders behave as they expect.

Source: UnitPrice · Destination: PRC

This is a recommended field. The price per unit that the customer was actually charged. Counterpoint accepts the line without it and creates the line with no unit price, so it should be mapped for accurate data. Because every line is flagged as having a price override — see HAS_PRC_OVRD below — this is the price Counterpoint uses, rather than the price it would have looked up from its own price rules. This is the behavior subscribers want when the source system has already settled the price at checkout.

Source: ExtendedPrice · Destination: EXT_PRC

This is a required field — NCR Counterpoint rejects the record without it. The extended price for the line — the line's total after quantity and any per-line discount. The order subtotal and total are recalculated in Counterpoint from the line extended prices, so this value, rather than the totals mapped on the parent collection, is what decides the order's value.

Subscribers transferring orders with header discounts should note that the extended price is expected to already carry its share of any header discount. Where the source system supplies an order-level discount without allocating it across the lines, the allocation has to be done with a formula on the iPaaS.com side before the order reaches this collection, or the resulting Counterpoint order will not balance.

Source: ExtendedPrice · Destination: CALC_EXT_PRC

This is a required field — NCR Counterpoint rejects the record without it, with the error Calc ext prc(CALC_EXT_PRC) is a required field. Counterpoint's calculated extended price for the line, which it records alongside the charged extended price so that the two can be compared. This mapping supplies the same source value as EXT_PRC above, so the two agree by default and the line shows no variance. Subscribers who want Counterpoint to show the difference between the price it would have calculated and the price actually charged should map this to the source system's own pre-discount line total instead.

Source: OriginalUnitPrice · Destination: CALC_PRC

This is a recommended field. The unit price before any discount, which Counterpoint records alongside the charged unit price in PRC above. Where the two differ, the line shows a price override with a visible amount, which is what makes discounted lines identifiable in Counterpoint reporting. Lines sold at full price carry the same value in both.

Source: EstimatedTaxAmount · Destination: TAX_AMT_ALLOC

This is a recommended field. The share of the order's tax that belongs to this line. Counterpoint accepts the line without it and records 0 instead, so it should be mapped for accurate data. Because every line is flagged as having a tax override — see HAS_TAX_OVRD below — Counterpoint does not calculate this for itself and uses what is supplied here. Subscribers should confirm that the line tax amounts arriving from their source add up to the order tax amount mapped on the parent collection, since Counterpoint records both and does not reconcile them.

Source: ItemNumberFromSku(Sku) · Destination: ITEM_NO

This is a required field — NCR Counterpoint rejects the record without it. The Counterpoint item number for the line. The formula reads it out of the iPaaS.com SKU, which carries more than the item number when the item has variants or alternate units: a vertical bar separates the item number from its grid dimensions, and a caret separates it from its selling unit. So a SKU of the form item, bar, colour, bar, size yields just the item number, and so does a SKU of the form item, caret, unit. A SKU with neither is used as-is.

The item number the formula produces must be an existing Counterpoint item. Presence is all that is checked during the transfer, not the item itself. An item number your installation does not have is accepted and stored on the line rather than being reported as a transfer error, and it then fails later — when the order is posted or used by another Counterpoint function — rather than at the point of transfer. A line for an item that never reached Counterpoint therefore transfers successfully and goes unnoticed until the order is worked on, so subscribers should transfer their products to Counterpoint before enabling this collection rather than relying on a transfer error to tell them a product is missing.

This depends on SKUs being held in that standard iPaaS.com form. Subscribers whose source system uses vertical bars or carets in its SKUs for some other purpose will find the item number cut at the first one. Where SKUs do not follow the standard form, replace this mapping with one that derives the item number the way the source data is actually structured.

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

This is a recommended field for gridded items, and it is supplied for every line regardless. Counterpoint accepts the line without it, but a gridded item recorded with no dimension is not identifiable as the variant the customer bought, so it should be mapped. The first grid dimension, read out of the iPaaS.com SKU by the same rules ITEM_NO above uses: the parts after the first vertical bar are the grid dimensions in order.

A SKU carrying no grid dimensions produces an asterisk rather than nothing. The asterisk is Counterpoint's marker for a dimension that does not apply, which is what makes this mapping safe to leave in place for non-gridded items — they are recorded as having no dimension rather than as having a missing one. The same is true where the SKU carries fewer dimensions than three.

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

This is a recommended field for gridded items, and it is supplied for every line regardless. The second grid dimension, read out of the iPaaS.com SKU. As with DIM_1_UPR above, a SKU that does not carry a second dimension produces an asterisk, marking the dimension as not applying.

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

This is a recommended field for gridded items, and it is supplied for every line regardless. The third grid dimension, read out of the iPaaS.com SKU. As with DIM_1_UPR above, a SKU that does not carry a third dimension produces an asterisk, marking the dimension as not applying.

Source: "Y" · Destination: HAS_TAX_OVRD

This is a required field — NCR Counterpoint rejects the record without it. It is a control mapping rather than a value: it tells Counterpoint not to calculate tax on the line and to use the amount supplied by TAX_AMT_ALLOC above instead. This is a genuine Counterpoint constant rather than an example, and it matches the tax override set at the order level on the parent collection.

Removing or changing it hands line tax calculation back to Counterpoint, which will usually disagree with the tax the customer was charged at checkout, and will leave the line tax at odds with the order tax the parent collection supplies.

Source: "O" · Destination: LIN_TYP

This is a required field — NCR Counterpoint rejects the record without it. Marks the line as an order line, matching the order-type document the parent collection creates. This is a genuine Counterpoint constant rather than an example, and it should be left as it is — a line whose type disagrees with its document produces a Counterpoint record that does not behave as an order.

Source: "Y" · Destination: HAS_PRC_OVRD

This is a recommended field, and it is a control mapping rather than a value. It tells Counterpoint not to recalculate the line price and to use the price supplied by PRC above instead. Counterpoint accepts the line without it and records N — no override — instead, so it should be mapped for accurate data. This is a genuine Counterpoint constant rather than an example.

Removing or changing it lets Counterpoint reprice the line from its own price rules, which will usually disagree with the price the customer paid at checkout. It is also what gives PRC_OVRD_REAS above its purpose: the reason code explains the price override to anyone reading the order.

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

This is an optional field. Its classification is taken from the role the mapping plays rather than from the Counterpoint schema, which carries no definition for it. Carries a gift card number through to Counterpoint where the source line has one. Gift card lines are not supported on orders, and this collection's Mapping Filter already excludes them, so in normal operation this mapping supplies nothing. It is a safeguard that preserves the gift card number rather than discarding it, should a line carrying one reach this collection.

Subscribers selling gift cards should use Add/Update NCR Counterpoint Gift Card FROM iPaaS.com and the deposit ticket collections rather than expect gift cards to transfer as order lines.

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

This is a recommended field, and it is a control mapping rather than a value. It marks whether the line is a gift card line. IS_GIFTCARD_LINE is not a column subscribers will find in their Counterpoint database — it tells the integration how to treat the line — so its classification is taken from the role the mapping plays rather than from the Counterpoint schema.

Because this collection's Mapping Filter excludes gift card lines, the mapping always resolves to false in normal operation. Subscribers who relax that filter should leave this mapping in place, since it is what would identify such a line if one arrived.

Source: "N" · Destination: CREATE_AS_STC

This is an optional field. CREATE_AS_STC is not a column subscribers will find in their Counterpoint database, so its classification is taken from the role the mapping plays rather than from the Counterpoint schema. It decides whether a gift card line would create a store credit rather than a gift card. Since this collection's Mapping Filter excludes gift card lines, it has no effect in normal operation and is present for consistency with the collections that do create gift cards.

Subscribers whose Counterpoint installation uses store credits should configure that behavior on the gift card and deposit ticket collections rather than here.

Source: Custom.SellingUnit · Destination: QTY_UNIT

This is a recommended field. The unit the line is sold in, taken from the selling unit held against the iPaaS.com line. Counterpoint accepts the line without it and creates the line with no unit recorded, so it should be mapped for accurate data. It sets the meaning of QTY_SOLD above: the same quantity against a different unit is a different amount of stock.

Where an item is sold in a unit other than its stocking unit, the unit is carried in the SKU after a caret and the selling unit reflects it. Subscribers should transfer their units to iPaaS.com with Add NCR Counterpoint Product Stocking Unit TO iPaaS.com and the product alternate unit collections so that the units arriving on order lines are units Counterpoint recognises for the item.

Source: "true" · Destination: EXPAND_KIT_CHILDREN

This is a recommended field, and it is a control mapping rather than a value. EXPAND_KIT_CHILDREN is not a column subscribers will find in their Counterpoint database — it tells the integration how to handle a line whose item is a kit — so its classification is taken from the role the mapping plays rather than from the Counterpoint schema.

Set as it is, a kit sold as a single line is written to Counterpoint as the kit together with its component lines, which is what lets Counterpoint relieve stock for the components. Subscribers who do not sell kits are unaffected by this mapping. Subscribers who do sell kits should transfer their kits with Add/Update NCR Counterpoint Product Kit TO iPaaS.com and its component collections so that the kits arriving on order lines are kits Counterpoint knows how to expand.

Source:

Destination: SER_NO

This is an optional field. The serial number for a serialised item. The formula reads a custom field named Serial Number from the iPaaS.com line and supplies it; where the line has no such custom field, or the field is empty, the formula supplies nothing and the line is created without a serial number.

This depends on a custom field named exactly Serial Number existing on the transaction line in iPaaS.com and being populated by the source system. Subscribers selling serialised items who name that field differently should change the name in the formula to match. This mapping works together with NO_OF_SERS_ENTD below, which tells Counterpoint how many serial numbers the line carries.

Source:

Destination: NO_OF_SERS_ENTD

This is an optional field. The count of serial numbers entered against the line. The formula reads the same custom field as SER_NO above and supplies a count of one where it holds a value, or nothing where it is empty or absent. This keeps the count consistent with the serial number itself, which matters because Counterpoint treats them as a pair.

Because the count is either one or nothing, a line carrying more than one serial number is not supported by this mapping as it stands. Subscribers selling several serialised units on a single line should confirm the behavior meets their needs in a staging environment before relying on it in production. Subscribers replacing either mapping should keep both derived from the same source.

Parent: Add NCR Counterpoint Order Line FROM iPaaS.com.

Mapping Filter

Filter Description.

Two conditions must hold. The first checks whether the line carries any discounts at all: a line sold at full price produces no discount record, rather than a record for zero. The second restricts the collection to a single record written once against the line, rather than once per source discount on it — which is what allows several discounts on one line to be summed into the one record Counterpoint holds against a line.

Source: "DISC$" · Destination: DISC_COD

This is a recommended field. The Counterpoint discount code the line's discount is recorded under. Counterpoint accepts the discount record without it and records it under no discount code, so it should be mapped for accurate data.

Placeholder value — replace during implementation: "DISC$" is an example discount code, not a Counterpoint default. It is a prompted amount discount code from a demonstration company. Replace it with a discount code configured in your own Counterpoint installation before enabling this collection. Discount codes are configured per installation, so the code that works in a demonstration company will not necessarily be one your installation knows. The replacement should be an amount discount code, since DISC_TYP below records the discount as an amount.

Source: "Website Line Discount" · Destination: DISC_DESCR

This is a recommended field. The description shown against the discount on the Counterpoint line. This is descriptive text rather than a code, so any wording transfers.

Placeholder value — replace during implementation: "Website Line Discount" is example wording, not a Counterpoint default. It names a website as the source of the discount, which will not be right for every subscriber. Replace it with wording that names the source your customers recognise, before enabling this collection. Because a line discount is what a customer sees against the item they bought, this wording is worth getting right rather than leaving as it ships.

Source: "L" · Destination: APPLY_TO

This is a required field — NCR Counterpoint rejects the record without it. It is a control mapping rather than a value. Allowed values: H, meaning the discount applies to the whole ticket, and L, meaning it applies to a line. Set as it is, the discount is recorded against the line, which is correct for this collection — it runs under each order line and records that line's own discount.

This is a genuine Counterpoint constant rather than an example and should be left as it is.

Source: "A" · Destination: DISC_TYP

This is a required field — NCR Counterpoint rejects the record without it. It is a control mapping rather than a value. Allowed values: A for an amount, B for an amount with a prompt, P for a percent, and Q for a percent with a prompt. Set as it is, the discount is recorded as a fixed amount.

This is a genuine Counterpoint constant rather than an example. It needs to agree with DISC_COD above, which should name an amount discount code. Subscribers whose source system expresses line discounts as percentages should still leave this as an amount: where a line carries several discounts they are added together, and the combined figure is an amount rather than any one rate.

Source: SumLineDiscountsForSingleLine(Parent.LineDiscounts) · Destination: DISC_AMT

This is a required field — NCR Counterpoint rejects the record without it. The total discount taken on this order line, held to two decimal places.

Source systems commonly allow several discounts on one line, while Counterpoint records a single discount against each line. The formula therefore adds together every discount on the iPaaS.com line and supplies the total as one figure. A line carrying both a promotion and a coupon arrives in Counterpoint as one discount for their combined value, so subscribers wanting to see which discounts made up that figure need to look to the source system rather than to Counterpoint.

Unlike the discount collections that write at the order level, this collection runs once for each discounted line, so a Counterpoint order can carry a discount on every line. It records the same money that Add NCR Counterpoint Order Line Header Discount Totals FROM iPaaS.com summarises into a single order-level figure — subscribers should confirm in a staging environment which of the two suits their reporting before enabling both, since the two describe the same discounts in different places.

There is no percentage mapping on this collection, so the line discount is recorded as an amount only. Subscribers who need a percentage on the Counterpoint line should validate in a staging environment that their installation behaves as they expect without one before relying on this collection in production.

Parent: Add NCR Counterpoint Order FROM iPaaS.com.

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

This is a recommended field. The Counterpoint pay code recorded against the payment. Counterpoint accepts the payment without it and records it with no pay code, so it should be mapped for accurate data. The iPaaS.com payment method is looked up in a translation collection and the matching Counterpoint pay code is written.

The translation ships with these pairs:

Two of the rows are conditions rather than plain values: they distinguish a gift card redemption from a store credit redemption by inspecting the payment, since both arrive as the same payment method.

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

This translation therefore needs review before the collection is enabled. As it ships, every card and wallet method resolves to the cash pay code, which means card payments are recorded in Counterpoint as cash and will not be separable in a Counterpoint cash drawer or deposit report. The pay codes on the right are also configured per Counterpoint installation, so the codes that work in a demonstration company will not necessarily be ones your installation knows. Subscribers or their MiSP should replace the destination values with pay codes from their own Counterpoint installation, confirm each one exists there, 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: (Status == "Authorized" ? "Y" : "N") · Destination: FINAL_PMT

This is a recommended field. Allowed values: Y and N. Marks the payment as the final payment on the order. Counterpoint accepts the payment without it and records N instead, so it should be mapped for accurate data.

A payment that has been authorized but not yet captured is recorded as a final payment; any other payment is not. This is what tells Counterpoint that no further payment is expected on the order even though no money has been taken against it yet, which is the normal shape of a card payment on a web order: the card is authorized at checkout and captured when the order ships.

This mapping works together with AMT and ORD_AMT below, which zero the amount for the same authorized payments. Subscribers replacing any one of the three should keep all three consistent — a payment marked final but carrying an amount, or the reverse, produces an order whose balance does not reflect what the customer will be charged.

Source: (Status == "Authorized" ? 0 : Amount) · Destination: AMT

This is a recommended field. The payment amount, held to two decimal places. Counterpoint accepts the payment without it and records 0 instead, so it should be mapped for accurate data.

A payment that has been authorized but not yet captured is recorded with an amount of zero, because no money has been taken and recording an amount would tell Counterpoint the order has been paid when it has not. Any other payment is recorded with its actual amount. Combined with FINAL_PMT above, an authorized card payment becomes a zero-value final payment: the order shows no money received, but Counterpoint knows the payment method is settled and no further payment is expected.

Subscribers whose source system captures payment at checkout rather than authorizing it will find their payments carrying their real amounts, which is the intended behavior.

Source: Description · Destination: DESCR

This is a required field — NCR Counterpoint rejects the record without it, with the error Description(DESCR) is a required field. The payment description carried from the iPaaS.com payment. Because the pay code from PAY_COD above collapses several source payment methods onto one Counterpoint code, this description is often the only place the original method is visible in Counterpoint. Subscribers who leave the pay code translation as it ships should keep this mapping, since it is what distinguishes one cash-coded payment from another. Subscribers whose source system can produce payments carrying no description should give this mapping a fallback value, since a payment that reaches Counterpoint without one is rejected.

Source:

Destination: GFC_NO

This is an optional field. The number of the gift card the payment was taken against. 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. Subscribers taking gift cards as payment should transfer their cards with Add/Update NCR Counterpoint Gift Card FROM iPaaS.com before orders paid with them arrive, since the conversion depends on the card being known.

Source:

Destination: STC_NO

This is an optional field. The number of the store credit the payment was taken against. 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.

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

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.

Source: (Status == "Authorized" ? 0 : Amount) · Destination: ORD_AMT

This is a recommended field. The amount of the payment applied to the order, held to two decimal places. Counterpoint accepts the payment without it and records 0 instead, so it should be mapped for accurate data.

This supplies the same value as AMT above, and it needs to keep doing so: Counterpoint applies a payment to an order by the order amount rather than by the payment amount, so a payment whose order amount is unmapped or different is recorded against the order without being applied to it, leaving the order looking unpaid. Subscribers replacing AMT should make the same change here.

Parent: Add NCR Counterpoint Order FROM iPaaS.com.

Source: LocalDateTimeFromDateTimeOffset(NoteCreatedDateTime) · Destination: NOTE_DAT

This is a recommended field. The date and time the note was written. iPaaS.com holds the moment together with its offset from universal time, while Counterpoint records a plain local date and time, so the formula converts one to the other rather than passing the value straight through. A note arriving without a created date produces nothing here.

Subscribers replacing this mapping should keep the conversion in place. Supplying the raw iPaaS.com value would leave Counterpoint recording a time that is right for the source system's time zone but wrong for the store's.

Source: SequenceNumber · Destination: NOTE_SEQ_NO

This is a required field — NCR Counterpoint rejects the record without it. The position of the note among the order's notes, carried straight from the iPaaS.com note. Together with the order it belongs to, this is what identifies the note in Counterpoint, so two notes on the same order need different sequence numbers.

Source: Type · Destination: NOTE_ID

This is a required field — NCR Counterpoint rejects the record without it. The note identifier, carried from the iPaaS.com note's type. This is what tells Counterpoint what kind of note it is holding, and it is how notes of different kinds stay distinguishable once they are on the order.

The value written is whatever the source system holds as the note type, which will not necessarily be worded the way your Counterpoint installation words it. Subscribers should confirm that the note types arriving from the source correspond to note identifiers their own Counterpoint installation recognises, and add a Lookup Translation to this mapping where they do not.

Source: Text · Destination: NOTE_TXT

This is a recommended field. The body of the note, carried straight from the iPaaS.com note. This is the note's whole content — Counterpoint accepts the note without it, but what arrives is an empty note, so it should be mapped for accurate data. Subscribers should validate how their own Counterpoint installation handles long or formatted note text in a staging environment before relying on it in production, since source systems commonly allow markup and line breaks that a Counterpoint note is not intended to carry.

Parent: Add NCR Counterpoint Order FROM iPaaS.com.

Mapping Filter

Filter Description.

This restricts the collection to a single tax record per order, written once against the order as a whole rather than once per source tax row. The mappings are built around that restriction: the tax amount supplied is the order's whole tax amount, so a second tax record on the same order would double the tax rather than split it. Subscribers should not relax this filter without also changing the amount mappings.

Source: "O" · Destination: TAX_DOC_PART

This is a recommended field. Marks the tax record as belonging to an order, matching the order-type document the parent collection creates. Counterpoint accepts the tax record without it and records S — sale — instead, which does not match the order-type document the parent collection creates, so it should be mapped for accurate data. This is a genuine Counterpoint constant rather than an example, and it should be left as it is — a tax record whose type disagrees with its document does not attach to the order as intended.

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

This is a required field — NCR Counterpoint rejects the record without it. The tax rule code on the order's tax record. It must also be a tax authority rule configured in your own Counterpoint installation.

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

The formula is written as a decision between three tax situations: a taxed order shipping to a nominated home state, a taxed order shipping anywhere else, and an untaxed order. It reads the state from the order's primary shipping address, falls back to the primary billing address when the order has no shipping address, and compares it against a state named in the formula.

Subscribers should be aware that in the template as shipped, all three branches return the same rule code, so the decision has no effect until the formula is edited — every order receives the one code regardless of destination or tax amount. The structure is there to be filled in, not to be relied on as-is. This is the same shape as the AUTH_COD mapping below and the TAX_COD mapping on the parent collection, and the three should be edited together.

Placeholder value — replace during implementation: the state name and the rule code in this formula are example values, not Counterpoint defaults. They name a single US state and a rule code from a demonstration company. Replace both with the state and the tax rule codes configured in your own Counterpoint installation before enabling this collection, and give each branch the code that belongs to it. Subscribers who do not need state-by-state rule codes should replace the formula with the single code their installation uses.

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

This is a required field — NCR Counterpoint rejects the record without it. The tax authority code on the order's tax record — the authority the tax is owed to. It must also be a tax authority configured in your own Counterpoint installation.

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

The formula has the same shape as RUL_COD above: it decides between a taxed order shipping to a nominated home state, a taxed order shipping anywhere else, and an untaxed order, reading the state from the order's primary shipping address and falling back to the primary billing address.

As with RUL_COD, in the template as shipped all three branches return the same authority code, so the decision has no effect until the formula is edited — every order is recorded against the one authority regardless of destination. Subscribers who owe tax to more than one authority need to edit this formula; leaving it as it is records out-of-state tax against the home authority.

Placeholder value — replace during implementation: the state name and the authority code in this formula are example values, not Counterpoint defaults. They name a single US state and an authority code from a demonstration company. Replace both with the state and the tax authority codes configured in your own Counterpoint installation before enabling this collection, and give each branch the code that belongs to it.

Source: Parent.TaxAmount · Destination: NORM_TAX_AMT

This is a recommended field. The normal tax amount — the tax Counterpoint would expect for the order before any override — taken from the tax amount on the parent order. Counterpoint accepts the tax record without it and records no normal tax amount, so it should be mapped for accurate data.

Because the parent collection sets a tax override on every order, this value and TAX_AMT below are supplied from the same source and agree by default, so the order shows no variance between expected and charged tax. Subscribers who want Counterpoint to show the difference between the tax it would have expected and the tax the customer was charged should map this to the source system's own calculated tax instead.

Source: Parent.TaxAmount · Destination: TAX_AMT

This is a recommended field. The tax charged on the order, taken from the tax amount on the parent order and held to two decimal places. Counterpoint accepts the tax record without it and records no tax amount against the authority, so it should be mapped for accurate data. Because the parent collection sets a tax override, this is the figure Counterpoint records rather than one it calculates.

This collection's Mapping Filter restricts it to one tax record per order, and the mapping is built around that: it supplies the order's whole tax amount, so a second tax record on the same order would double the tax rather than split it. Subscribers whose source system reports tax broken down by authority — several jurisdictions on one order, or a tax service reporting alongside the standard authorities — get a single combined Counterpoint tax record carrying the order's total, recorded against the single authority set by AUTH_COD above. Subscribers who need tax split across authorities in Counterpoint should validate that behavior in a staging environment before relying on it in production, since this collection as it stands does not produce it.

Parent: Add NCR Counterpoint Order FROM iPaaS.com.

Mapping Filter

Filter Description.

Two conditions must hold. The first restricts the collection to a single record written once against the order as a whole, rather than once per source discount — which is what allows the several source discounts to be summed into the one record Counterpoint holds. The second checks whether the order carries any order-level discounts at all: an order with none produces no discount record, rather than a record for zero.

Source: "0" · Destination: DISC_SEQ_NO

This is a required field — NCR Counterpoint rejects the record without it. The position of the discount among the order's discounts. This collection produces exactly one discount record per order — the Mapping Filter restricts it to a single record, and the amount mapped below is the sum of every header discount on the order — so the sequence number is fixed at the first position. This is a genuine constant here rather than an example, and it follows from the collection producing one record.

Source: "DOCAMT2" · Destination: DISC_COD

This is a recommended field. The Counterpoint discount code the order's header discount is recorded under. Counterpoint accepts the discount record without it and records it under no discount code, so it should be mapped for accurate data.

Placeholder value — replace during implementation: "DOCAMT2" is an example discount code, not a Counterpoint default. It is a prompted amount discount code from a demonstration company. Replace it with a discount code configured in your own Counterpoint installation before enabling this collection. Discount codes are configured per installation, so the code that works in a demonstration company will not necessarily be one your installation knows. The replacement should be an amount discount code, since DISC_TYP below records the discount as an amount.

Source: "Website Line Discount" · Destination: DISC_DESCR

This is a recommended field. The description shown against the discount in Counterpoint. This is descriptive text rather than a code, so any wording transfers.

Placeholder value — replace during implementation: "Website Line Discount" is example wording, not a Counterpoint default, and it does not describe what this collection writes. This collection records discounts taken at the order level, not line discounts, so the wording is misleading as it ships — a subscriber reading a Counterpoint order will see order-level discounts labelled as line discounts. Replace it with wording that describes an order-level discount and names the source your customers recognise, before enabling this collection.

Source: "H" · Destination: APPLY_TO

This is a required field — NCR Counterpoint rejects the record without it. It is a control mapping rather than a value. Allowed values: H, meaning the discount applies to the whole ticket, and L, meaning it applies to a line. Set as it is, the discount is recorded against the ticket, which is correct for this collection — the discounts it sums were taken at the order level in the first place.

This is a genuine Counterpoint constant rather than an example and should be left as it is. Changing it to a line discount would record an order-level discount against a line that did not receive it.

Source: "A" · Destination: DISC_TYP

This is a required field — NCR Counterpoint rejects the record without it. It is a control mapping rather than a value. Allowed values: A for an amount, B for an amount with a prompt, P for a percent, and Q for a percent with a prompt. Set as it is, the discount is recorded as a fixed amount.

This is a genuine Counterpoint constant rather than an example. It needs to agree with DISC_COD above, which should name an amount discount code, and it is why DISC_AMT below carries the discount and DISC_PCT is supplied alongside it for reference. Subscribers whose source system expresses order discounts as percentages should still leave this as an amount: the amount is the figure the customer was actually given, and it is what makes the order balance.

Source: SumHeaderDiscounts(Parent.Discounts) · Destination: DISC_AMT

This is a required field — NCR Counterpoint rejects the record without it. The total order-level discount, held to two decimal places.

Source systems commonly allow several discounts on one order, while Counterpoint records a single discount against the ticket. The formula therefore adds together every order-level discount on the iPaaS.com order and supplies the total as one figure. An order carrying three promotions arrives in Counterpoint as one discount for their combined value, so subscribers wanting to see which promotions made up that figure need to look to the source system rather than to Counterpoint.

This is the same total the ORD_TOT_HDR_DISC mapping on the parent collection supplies. The two work together: the parent records the discount total on the order, and this collection writes the discount record itself. The discount amount is added back into the order's gross subtotal and total during the transfer, so the source system must already have allocated the discount into each line's extended price for the resulting order to balance.

Source: SumHeaderDiscountPercentage(Parent.Discounts, Parent.Subtotal) · Destination: DISC_PCT

This is a required field — NCR Counterpoint rejects the record without it, with the error Disc %(DISC_PCT) is a required field. The order-level discount expressed as a percentage of the order subtotal, supplied alongside the amount so that Counterpoint can show the discount either way.

The formula adds together every order-level discount on the iPaaS.com order and works out what proportion of the order subtotal that total represents. Because DISC_TYP above records the discount as an amount, this percentage is held for reference rather than used to calculate the discount — the amount in DISC_AMT above is the figure that decides what the customer was given. Subscribers should expect the percentage to be a derived figure that may not match any single promotion's advertised rate, since it describes the combined discount against the subtotal.

Parent: Add NCR Counterpoint Order FROM iPaaS.com.

Mapping Filter

Filter Description.

Two conditions must hold. The first restricts the collection to a single record written once against the order as a whole, rather than once per line — which is what allows the discounts from several lines to be summed into the one record Counterpoint holds. The second checks whether the order's lines carry any discounts at all: an order whose lines were all sold at full price produces no discount record, rather than a record for zero.

Source: "0" · Destination: DISC_SEQ_NO

This is a required field — NCR Counterpoint rejects the record without it. The position of the discount among the order's discounts. This collection produces exactly one discount record per order — the Mapping Filter restricts it to a single record, and the amount mapped below is the sum of every line discount on the order — so the sequence number is fixed at the first position. This is a genuine constant here rather than an example, and it follows from the collection producing one record.

Subscribers running this collection alongside Add NCR Counterpoint Order Header Discount Totals FROM iPaaS.com should note that both write a discount record to the same order at the same sequence number. Where an order carries both line discounts and order-level discounts, the two collections write to the same place, so subscribers should confirm in a staging environment that orders of that shape produce the discount record they expect before relying on the pair in production.

Source: "DISC$" · Destination: DISC_COD

This is a recommended field. The Counterpoint discount code the order's line discount total is recorded under. Counterpoint accepts the discount record without it and records it under no discount code, so it should be mapped for accurate data.

Placeholder value — replace during implementation: "DISC$" is an example discount code, not a Counterpoint default. It is a prompted amount discount code from a demonstration company. Replace it with a discount code configured in your own Counterpoint installation before enabling this collection. Discount codes are configured per installation, so the code that works in a demonstration company will not necessarily be one your installation knows. The replacement should be an amount discount code, since DISC_TYP below records the discount as an amount.

Source: "Website Line Discount" · Destination: DISC_DESCR

This is a recommended field. The description shown against the discount in Counterpoint. This is descriptive text rather than a code, so any wording transfers.

Placeholder value — replace during implementation: "Website Line Discount" is example wording, not a Counterpoint default. It names a website as the source of the discount, which will not be right for every subscriber. Replace it with wording that names the source your customers recognise, before enabling this collection. Subscribers running this collection alongside the other discount collections should give each a distinct description, since the wording is what tells the three apart on a Counterpoint order.

Source: "L" · Destination: APPLY_TO

This is a required field — NCR Counterpoint rejects the record without it. It is a control mapping rather than a value. Allowed values: H, meaning the discount applies to the whole ticket, and L, meaning it applies to a line. Set as it is, the discount is marked as a line discount, which reflects where the discounts it sums came from — they were taken on the order's lines, even though this collection records their total against the order rather than against each line.

This is a genuine Counterpoint constant rather than an example and should be left as it is. It is what distinguishes this collection's record from the one written by Add NCR Counterpoint Order Header Discount Totals FROM iPaaS.com, which records discounts that were taken at the order level in the first place.

Source: "A" · Destination: DISC_TYP

This is a required field — NCR Counterpoint rejects the record without it. It is a control mapping rather than a value. Allowed values: A for an amount, B for an amount with a prompt, P for a percent, and Q for a percent with a prompt. Set as it is, the discount is recorded as a fixed amount.

This is a genuine Counterpoint constant rather than an example. It needs to agree with DISC_COD above, which should name an amount discount code. Subscribers whose source system expresses line discounts as percentages should still leave this as an amount: once several line discounts are added together, the combined figure is an amount rather than any one rate.

Source: SumLineDiscounts(Parent.Lines) · Destination: DISC_AMT

This is a required field — NCR Counterpoint rejects the record without it. The total of every discount taken on the order's lines, held to two decimal places and recorded against the order.

Source systems commonly allow several discounts on a line and several discounted lines on an order, while Counterpoint records a single discount against the ticket and a single discount against each line. This collection handles the first of those: it walks the order's lines, adds together every discount found on them, and writes the total once at the order level. An order with three discounted lines therefore produces one Counterpoint discount record for their combined value.

This is a different view of the same money that Add NCR Counterpoint Order Line Discount Totals FROM iPaaS.com records line by line. Subscribers who want line discounts visible on the individual Counterpoint lines rather than summarised at the order should use that collection; subscribers who want the order total should use this one. Subscribers should confirm in a staging environment which of the two suits their reporting before enabling both, since the two describe the same discounts in different places.

Source: SumLineDiscountPercentageOfHeader(Parent.Lines, Parent.Subtotal) · Destination: DISC_PCT

This is a required field — NCR Counterpoint rejects the record without it, with the error Disc %(DISC_PCT) is a required field. The order's total line discount expressed as a percentage of the order subtotal, supplied alongside the amount so that Counterpoint can show the discount either way.

The formula adds together every discount taken on the order's lines and works out what proportion of the order subtotal that total represents. Because DISC_TYP above records the discount as an amount, this percentage is held for reference rather than used to calculate the discount — the amount in DISC_AMT above is the figure that decides what the customer was given. The percentage is measured against the order subtotal rather than against the discounted lines alone, so on an order where only some lines were discounted it will read lower than the rate any one line received.

Mapping Filter

Filter Description.

Only transactions whose iPaaS.com status is Cancelled and whose type is Order are processed. Orders that still have an open deposit ticket against them are skipped, so an order holding a deposit is not cancelled by this collection and is instead handled through the deposit refund flow — cancellations of orders whose deposit has been refunded flow through Add NCR Counterpoint Deposit Refund FROM iPaaS.com. Transactions whose number ends in -D or -GC are also excluded, as those suffixes mark records belonging to the deposit and gift card flows rather than to the order flow. Subscribers who relax this filter should be aware that admitting orders with an open deposit would cancel them without addressing the money already taken against them.

Source: "BC" + TransactionNumber · Destination: TKT_NO

This is a required field — NCR Counterpoint rejects the record without it. It is the ticket number the update is applied against, so it is what tells NCR Counterpoint which order to cancel. The formula takes the iPaaS.com transaction number and puts a two-character prefix in front of it. The prefix exists so that orders arriving from iPaaS.com are distinguishable from tickets entered directly in Counterpoint.

The value this formula builds must match the ticket number the order was originally created with, or the cancellation has no order to apply to. This collection does not create orders — it only updates ones already in Counterpoint. Subscribers changing the prefix must therefore change it in the same way on every collection that writes a ticket number, and must keep it at two characters, because the prefix is part of the ticket number Counterpoint stores and matches on.

Placeholder value — replace during implementation: "BC" is an example prefix, not a Counterpoint default. It was chosen for a specific pairing rather than as a general-purpose value. Replace it with a prefix that suits your own Counterpoint installation before enabling this collection, keeping it to two characters, and apply the same prefix consistently across every collection that writes a ticket number.

Source: "C" · Destination: DOC_STAT

This is a recommended field. Counterpoint accepts the record without it and records O — the open status — instead, so it should be mapped for accurate data: it is the value the collection exists to write, and removing it leaves the order open rather than cancelled. It sets the order's document status to cancelled. Cancelling an order in Counterpoint needs no more than this one field, which is why this collection carries only the status and the ticket number that identifies the order.

This is a genuine Counterpoint status value rather than an example, so it does not need changing for a typical install. Any replacement must be a document status Counterpoint recognises for an order, and setting anything other than the cancelled status here would stop the collection doing what it is for.

Cancellation here is a status change, not a deletion — the order stays in Counterpoint and remains visible in reporting. Subscribers should note that the collection cancels the order outright rather than reversing any money already taken against it. Deposits are handled separately: the Mapping Filter skips any order that still has an open deposit ticket, so orders holding a deposit are not cancelled by this collection and are instead handled through the deposit refund flow. Cancellations of orders whose deposit has been refunded flow through Add NCR Counterpoint Deposit Refund FROM iPaaS.com.

This collection updates orders. Subscribers writing sales directly rather than managing orders through Counterpoint should use the Add NCR Counterpoint Sale Ticket FROM iPaaS.com mappings instead, and disable this collection — a sale ticket records a completed sale rather than an order that can later be cancelled, so the two describe different flows and are not intended to run together.

Mapping Filter

Filter Description.

Only transactions whose iPaaS.com status is Complete are processed, so an order still in progress is not flagged for release. Three kinds of record are then excluded: transactions whose number ends in -D, transactions whose number ends in -GC, and transactions whose type is Validated Return. The two suffixes mark records that belong to the deposit and gift card flows rather than to the order flow, and a validated return is not an order to be released. Subscribers who change this filter should confirm that anything they admit is genuinely a Counterpoint order that already exists and can be flagged for release, because this collection does not create orders.

Source: "BC" + TransactionNumber · Destination: TKT_NO

This is a required field — NCR Counterpoint rejects the record without it. It is the ticket number the update is applied against, so it is what tells NCR Counterpoint which order to mark as complete. The formula takes the iPaaS.com transaction number and puts a two-character prefix in front of it. The prefix exists so that orders arriving from iPaaS.com are distinguishable from tickets entered directly in Counterpoint.

The value this formula builds must match the ticket number the order was originally created with, or the update has no order to apply to. This collection does not create orders — it only updates ones already in Counterpoint. Subscribers changing the prefix must therefore change it in the same way on every collection that writes a ticket number, and must keep it at two characters, because the prefix is part of the ticket number Counterpoint stores and matches on.

Placeholder value — replace during implementation: "BC" is an example prefix, not a Counterpoint default. It was chosen for a specific pairing rather than as a general-purpose value. Replace it with a prefix that suits your own Counterpoint installation before enabling this collection, keeping it to two characters, and apply the same prefix consistently across every collection that writes a ticket number.

Source: "Y" · Destination: PROF_ALPHA_5

This is a recommended field. Counterpoint accepts the update without it, but it is the value the collection exists to write, and removing it leaves the update with nothing to change. It flags the order as ready to release. Subscribers who use Counterpoint's batch release process can filter on this profile field to pick up orders that iPaaS.com has reported complete, rather than identifying them by hand.

This is a profile field rather than a fixed-purpose Counterpoint field, which means Counterpoint attaches no meaning to it on its own. It carries meaning only because a Counterpoint-side batch release filter has been set up to look for it. A subscriber who has not configured that filter sees the flag written and nothing act on it.

Placeholder value — replace during implementation: "Y" is an example flag value written to an example profile field, not a Counterpoint default. Replace the value, the profile field, or both with the ones your own Counterpoint installation uses for batch release before enabling this collection, and confirm the Counterpoint-side release filter reads the same field and value this mapping writes. Subscribers whose orders are already flagged for release by other means, or who use a profile field for another purpose, should confirm this mapping does not overwrite data they rely on.

This collection updates orders. Subscribers writing sales directly rather than releasing orders through Counterpoint should use the Add NCR Counterpoint Sale Ticket FROM iPaaS.com mappings instead, and disable this collection — the two describe different ways of completing a sale, and running both puts two records into Counterpoint for the same iPaaS.com transaction.

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.