0% found this document useful (0 votes)

735 views67 pages

Implementation Guide POS Back Office: June 4, 2018

Uploaded by

Sebastian Amaro

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

735 views67 pages

Implementation Guide POS Back Office: June 4, 2018

Uploaded by

Sebastian Amaro

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 67

Implementation Guide

POS Back Office

June 4, 2018
Version 3.6

Document Summary
This guide provides implementers with the information and knowledge required to
implement the POS/Back Office Interface Specification.

The POS/Back Office Interface Specification is intended to facilitate the transfer of

configuration and reporting data between the POS and Back Office systems.

Configuration and reporting for site, merchandise, fuel, taxes, tender, and workforce, as
well as reporting for the POS Journal, are covered.

POSBO_ImplementationGuide Page 1 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
Contributors
Allie Russell, Conexxus
Bill Wade, PDI
Chris Tauchnitz, Verifone
David Ezell, VeriFone, Inc.
David Godwin, VeriFone, Inc.
Gregg Peele, CMI Solutions, Inc.
Jeff Shein, NCR
Jim Koch, NCR
Keith Hess, ALON Brands
Kim Seufer, Conexxus
Linda Toth, Conexxus
Lisa Hester, Gilbarco Veeder-Root
Sam Pfanstiel, Coalfire
Scott Wood, PCATS
Raymond Lugo, SSCS
Tony Ross, PDI

POSBO_ImplementationGuide Page 2 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
Revision History
Revision Date Revision Revision Editor(s) Revision Changes
Number
June 4, 2018 Version 3.6 Linda Toth, Conexxus Release Version
March 12, 2018 Draft 1.13 Kim Seufer, Conexxus Changes incorporated from
Committee vote
February 12, Draft 1.12 Kim Seufer, Conexxus Changes from review of
2018 Committee meeting on
February 12, 2018. Added
watermark.
February 9, Draft 1.11 David Ezell, Verifone Cleaned up examples
2018
January 17, Draft 1.10 Linda Toth, Conexxus Changes from reviews
2018
January 9, Draft 1.9 Bill Wade, PDI Added language to sections
2018 David Ezell, Conexxus 8.2.1 and 8.3.1
December 1, Draft 1.8 Kim Seufer, Conexxus Formatting changes
2017
October 6, 2017 Draft 1.7 David Ezell, Verifone Preliminary updates for v3.6
October 16, 1.6 Linda Toth, Conexxus - Release Version
2014
September 23, Draft 1.6 Linda Toth, Conexxus - Updated with feedback from
Public Comment Period
2014
- Updated copyright
May 28, 2014 Draft 1.5 Linda Toth, Conexxus Changes for Conexxus
March 29, 2014 Draft 1.4 Linda Toth, PCATS - Updated with feedback from
SQA and Counsel reviews
February 21, Draft 1.3 Linda Toth ,PCATS - Updated with feedback from
committee member reviews
2014
February 1, Draft 1.2 Linda Toth, PCATS - Updated Axis Reporting
- Incorporated committee
2014 review and comments
January 26, Draft 1.1 Linda Toth, PCATS - Updated copyright and
disclaimer
2014 - Reorganized Document
- Improved readability and
clarity
- Adjusted formatting
- Extensive rewrites and
additions to provide improved
content

POSBO_ImplementationGuide Page 3 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
May 17, 2014 1.0.1 Linda Toth, Conexxus Changes for Conexxus
Nov 5, 2012 1.0 Linda Toth, PCATS Approved for Release
April 23, 2012 Draft 0.2 Linda Toth, PCATS - Updated data models for site
and taxes
- Replaced TaxLevelID in
TSTDetail examples with
preferred element
TaxStrategyTaxLevelID
- Minor wording changes in the
introduction
March 28, 2012 Draft 0.1 Linda Toth, PCATS Initial version in new format

POSBO_ImplementationGuide Page 4 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
Copyright Statement
Copyright © CONEXXUS, INC. 2014-2018, All Rights Reserved.

Conexxus members may use this document for purposes consistent with the adoption
of the Conexxus Standard; however, Conexxus must pre-approve any inconsistent uses in
writing.

Conexxus recognizes that a Member may wish to create a derivative work that
comments on, or otherwise explains or assists in implementation, including citing or
referring to the standard, specification, protocol, schema, or guideline, in whole or in part.
The member may do so, but may share such derivative work ONLY with another Conexxus
Member who possesses appropriate document rights (i.e., Gold or Silver Members) or with
a direct contractor who is responsible for implementing the standard for the Member. In so
doing, a Conexxus Member should require its development partners to download Conexxus
documents and schemas directly from the Conexxus website. A Conexxus Member may
not furnish this document in any form, along with any derivative works, to non-
members of Conexxus or to Conexxus Members who do not possess document rights
(i.e., Bronze Members) or who are not direct contractors of the Member. A Member
may demonstrate its Conexxus membership at a level that includes document rights by
presenting an unexpired digitally signed Conexxus membership certificate.

This document may not be modified in any way, including removal of the copyright
notice or references to Conexxus. However, a Member has the right to make draft
changes to schema for trial use, before submission to Conexxus for consideration to be
included in the existing standard. Translations of this document into languages other
than English shall continue to reflect the Conexxus copyright notice.

The limited permissions granted above are perpetual and will not be revoked by
Conexxus, Inc. or its successors or assigns, except in the circumstance where an entity,
who is no longer a member in good standing but who rightfully obtained Conexxus
Standards as a former member, is acquired by a non-member entity. In such
circumstances, Conexxus may revoke the grant of limited permissions or require the
acquiring entity to establish rightful access to Conexxus Standards through
membership.

POSBO_ImplementationGuide Page 5 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
Disclaimers
Conexxus makes no warranty, express or implied, about, nor does it assume any legal
liability or responsibility for, the accuracy, completeness, or usefulness of any
information, product, or process described in these materials. Although Conexxus uses
reasonable best efforts to ensure this work product is free of any encumbrances
resulting from third party intellectual property rights (IPR), it cannot guarantee that
such IPR does not exist now or in the future. Conexxus further notifies all users of this
standard that their individual method of implementation may result in infringement of
the IPR of others. Accordingly, each user is encouraged to carefully review its
implementation of this standard and obtain appropriate licenses where needed.

POSBO_ImplementationGuide Page 6 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
Table of Contents

1 Introduction and Overview ........................................................................................ 10

2 Architecture ................................................................................................................ 11
3 Security Considerations ............................................................................................. 12
4 Protocol ...................................................................................................................... 12
5 Data Model ................................................................................................................. 13
5.1 Site ...................................................................................................................... 15
5.2 Merchandise ....................................................................................................... 16
5.3 Fuel ......................................................................................................................17
5.4 Taxes ................................................................................................................... 18
5.5 Tender ................................................................................................................. 19
5.6 Workforce ........................................................................................................... 20
5.7 POS Journal ........................................................................................................ 21
6 Data Specification ...................................................................................................... 23
6.1 Configuration ...................................................................................................... 23
6.1.1 QUAID............................................................................................................. 23
6.1.2 Site ............................................................................................................... 23
6.1.3 Merchandise ................................................................................................ 23
6.1.4 Fuel .............................................................................................................. 24
6.1.5 Taxes ............................................................................................................... 25
6.1.6 Workforce .................................................................................................... 25
6.2 Reporting ............................................................................................................ 26
6.2.1 Site ............................................................................................................... 26
6.2.2 Merchandise ................................................................................................ 26
6.2.3 Fuel .............................................................................................................. 27
6.2.4 Taxes ............................................................................................................ 27
6.2.5 Tender ......................................................................................................... 28
6.3 POS Journal ........................................................................................................ 28

POSBO_ImplementationGuide Page 7 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
7 Internationalization ................................................................................................... 29
8 Implementation Details ............................................................................................. 29
8.1 Working Samples................................................................................................ 29
8.2 Configuration ...................................................................................................... 30
8.2.1 QUAID ......................................................................................................... 30
8.2.2 Site ............................................................................................................... 33
8.2.3 Merchandise ................................................................................................ 34
8.2.4 Fuel .............................................................................................................. 37
8.2.5 Taxes ............................................................................................................ 37
8.2.6 Workforce .................................................................................................... 44
8.3 Reporting ............................................................................................................ 44
8.3.1 Reporting Conventions ............................................................................... 44
8.3.2 Reporting Process and Periods ................................................................... 45
8.3.3 Movement Report Request ......................................................................... 46
8.3.4 Axis Reporting ............................................................................................. 47
8.3.5 Site ............................................................................................................... 49
8.3.6 Merchandise ................................................................................................ 49
8.3.7 Fuel .............................................................................................................. 51
8.3.8 Taxes ............................................................................................................ 51
8.3.9 Tender ......................................................................................................... 52
8.4 Journal ................................................................................................................ 53
8.4.1 Journal Conventions ................................................................................... 53
8.4.2 Promotions, Discounts and other Reductions in Price .............................. 57
8.4.3 Taxes ............................................................................................................ 58
8.4.4 Fuel .............................................................................................................. 59
8.4.5 Linked Items and Fees ................................................................................ 60
8.4.6 Pay In and Pay Out ...................................................................................... 60
8.4.7 Coupons ....................................................................................................... 60
8.4.8 Foreign Currency ........................................................................................ 61

POSBO_ImplementationGuide Page 8 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
8.4.9 Entry Methods............................................................................................. 61
8.4.10 Sale Events .................................................................................................. 61
8.4.11 Refund Events ............................................................................................. 62
8.4.12 Void Events ................................................................................................. 63
8.4.13 Financial Events .......................................................................................... 63
8.4.14 Other Events................................................................................................ 63
8.5 Extensions .......................................................................................................... 64

POSBO_ImplementationGuide Page 9 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
Project
POS Back Office

1 Introduction and Overview

This guide provides implementers with the information and knowledge required to
implement the POS/Back Office Interface Specification (Specification). Point-of-Sale
(POS) systems (forecourt and in-store systems used for controlling and reporting sales)
are responsible for enabling transactions between customers and retailers. Back Office
Systems (systems that maintain configuration data and provide reporting services) are
often responsible for configuring the POS.

The Specification is intended to facilitate the transfer of configuration and reporting

data between the POS and Back Office systems. The Specification is comprised
primarily of a collection of XML Schema (.xsd) documents describing various document
structures for configuration and reporting of data. Configuration documents permit the
exchange of configuration data between the Back Office and POS systems, while
reporting documents permit the transmission of reports regarding sales and other
activities. Documents are broadly categorized as follows:

• Site: Site data includes fundamental information regarding a specific retail site
(store). A retail site is a physical location in which products and services are
offered for sale to the public. A site has certain fundamental characteristics (e.g.,
ID, name, address, phone number) that should be consistent across all
components of the retailer’s business information systems. Site documents
describe those fundamental characteristics by which that information may be
shared between system components;
• Merchandise: Merchandise codes are used to categorize products and services
for sale by retail businesses. Hierarchical categories are supported;
• Fuel: Fuel and fueling equipment configuration and reporting provides the
means to track inventory and sales of grades and products at the site;
• Taxes: POS systems must collect sales, use, and other taxes based on state, local
and regional laws. A Back Office System can configure the POS so proper taxes
are collected. Reporting allows retrieval of paid taxes from the POS once
transactions occur;
• Workforce: Configuration and reporting related to employees, tasks, and
schedules;
• Tender: (Reporting only) Tender reports describe activities with respect to
methods of payment; and
• POS Journal: Transaction-level detailed report regarding activities conducted on
or routed to or through the POS system.

POSBO_ImplementationGuide Page 10 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
2 Architecture
A key component of the software architecture is the POS-to-Back Office System
topology, which focuses on the interface between the two systems. In general, the
interface consists of defining various kinds of sales data (both real-time and summary),
as well as necessary configuration data that can keep the systems coordinated.

Configuration – Pricebook,
scheduling, etc.

Back Office
POS System
System

Journals and Reports

Figure 1: Architecture Diagram

The software architecture defines the documents in the exchange, as well as the
relationships implicit in the data contained in those documents. The Specification takes
into account that implementation of these documents, as used by various combinations
of POS and Back Office systems, will vary and must be flexible.

This structure addresses some of the key elements normally found in well-defined
software architectures:

• Separation of concerns, i.e., keeping data separate from transport;

• Recurring styles, i.e., using common data structures for common purposes; and
• Conceptual integrity, i.e., providing common definitions and language for
addressing the issues involved.

POSBO_ImplementationGuide Page 11 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
3 Security Considerations
Depending on the implementation, several elements within the POS Journal’s
SaleEvent complex element should be evaluated to determine if they contain sensitive
data. In particular, AccountInfo and Authorization complex elements each
include sub elements that could contain sensitive data, and thus present security risks if
not secured properly. The contents of AccountInfo include AccountID as well as
other fields that may pose security risks. Of special concern is the CardInfo element
included in Authorization, which may contain PCI cardholder data (CHD).

Starting with version 3.6 of the schemas, some of these fields are now optional. It is also
worth noting that CardInfo may be marked as deprecated in future versions of this
Specification, which should help to reduce security risks associated with its misuse.

Similarly, the CustomerID element contains fields that could contain personally
identifiable information (PII), some of which may be required by certain
implementations (e.g., PersonalID, BirthDate). While BirthDate may or may not
be considered PII when viewed alone, when it is associated with other PII there is a risk
that disclosure could impact consumer privacy.

It is incumbent upon the implementer to take due care in transmission of sensitive data
(e.g., PII, CHD). It is recommended that data encryption, transformation, and/or
truncation be used to reduce the risks associated with disclosure of sensitive data that
may be present in these fields.

Implementations should support the transmission and storage of sensitive data only if
absolutely required.

4 Protocol
The protocol for the NAXML POS/Back Office interface is "document exchange." The
Specification supports the following usage scenarios:

• Unsolicited configuration (normally Back Office to POS) in the form of an Update,

Addition, Initialization, or Deletion, see QUAID;
• Query for configuration (normally from Back Office to POS in order to verify
configuration), see QUAID;
• Unsolicited reporting (normally from POS to Back Office); and
• Query for reporting (normally from Back Office to POS).

POSBO_ImplementationGuide Page 12 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
Up through this version of the Specification there is no explicit design or specific
recommendation for:

• Communication format;
• Transmission security (i.e., authentication or encryption);
• Acknowledgements; or
• Response documents (i.e., indicating success or failure).

Partners collaborating to implement the Specification must resolve these issues in a way
that works in their respective environments.

5 Data Model
The following Data Models shows the relationships between various entities in the
Specification. The data details for these entities (i.e., what they contain) is best found
either in the XML Schema documents for the Specification or in the following sections.

The Data Model is comprised of:

• Maintenance Entities (yellow) – used for configuration;

• Movement Entities (green) – used for reporting;
• Journal Entities – used in the transaction journal; and
• Relationship Entities (gray) – do not actually appear as independent items in the
Specification, but provide logical relationships.

The Maintenance Entities and Movement Entities data model consists of several data
sets: Site, Merchandise, Fuel, Taxes, Tender, and Workforce. The Journal Entities data
model is a self-contained model.

POSBO_ImplementationGuide Page 13 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
FuelPosition

PK FuelPositionID

FK1 PriceTierCode TankProduct Tank Movement

Site ReasonCode Schedule Task Employee FK1 ServiceLevelCode
PK TankID PK,FK1 TankID
FK1 TimeTierCode
PK SiteID PK ReasonCode PK EmployeeID FK2 TankID
TankIDHigh
SiteTrait[] FK1 FuelGradeID

TaxIncludes
FuelGradeAxis Movement
PK TaxLevelID
PK,FK1 FuelGradeID
FuelGrade FK1 PriceTierCode
PK FuelGradeID FK1 ServiceLevelCode
TaxLevel Movement PK PriceTierCode FK1 TimeTierCode
TaxLevel TaxStrategy MerchandiseCode
PK ServiceLevelCode
PK,FK1 TaxLevelID PK TaxLevelID PK MerchandiseCode PK TimeTierCode
PK TaxStrategyID
FuelProduct FuelProduct Movement
FK1,FK2 TaxLevelID FK1 TaxStrategyID FK1 FuelProductID
FuelProductIDHigh PK FuelProductID PK,FK1 FuelProductID
FK2 MerchandiseCode
FK3 TaxStrategyID
ItemSales Movement Item
PK,FK1 ItemCode PK ItemCode FuelGrade Movement
PK ItemID
FK1 MerchandiseCode FuelPriceChange PK,FK1 FuelGradeID
FK2 TaxStrategyID MixMatch
PK,FK1 PriceTierCode FK1 PriceTierCode
PK PromotionID PK,FK1 ServiceLevelCode FK1 ServiceLevelCode
PK,FK1 TimeTierCode FK1 TimeTierCode
FK1 ItemListID PK,FK1 FuelGradeID

Combo Movement Combo MiscellaneousSummary Movement

ItemList
PK,FK1 PromotionID PK PromotionID PK MiscellaneousSummaryCode
PK ItemListID
PK,FK1 Tender
FK1 ItemListID[]
FK2 ItemCode[] FK1 ItemCode Tender

PK Tender
TenderSummary Movement

PaymentSystemsSummary Movement MerchandiseCode Movement PK,FK1 Tender

PK PaymentSystemsProductCode PK,FK1 MerchandiseCode

BatchSummaryAxis Movement

PK BatchID

BatchSummary Movementl

PK BatchID

Figure 2: Maintenance and Movement Data Model

POSBO_ImplementationGuide Page 14 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
5.1 Site
The Site and ReasonCode data sets are two of a group of standalone tables designed to configure operations on a POS.
MiscellaneousSummary Movement is used for reporting various key performance indicators from the POS.

Site MiscellaneousSummary Movement

PK SiteID PK MiscellaneousSummaryCode
PK,FK1 Tender
SiteTrait[]

ReasonCode

PK ReasonCode Tender

PK Tender

Figure 3: Site Data Model

POSBO_ImplementationGuide Page 15 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
5.2 Merchandise
The merchandise data model represents the organizing structure for grouping products for sale, pricing those products,
and then reporting the results of individual transactions or a group of transactions.

TaxStrategy MerchandiseCode

PK TaxStrategyID PK MerchandiseCode

FK1 TaxStrategyID

ItemSales Movement Item

PK,FK1 ItemCode PK ItemCode

PK ItemID
FK1 MerchandiseCode
FK2 TaxStrategyID MixMatch

PK PromotionID

FK1 ItemListID

Combo Movement Combo

ItemList
PK,FK1 PromotionID PK PromotionID
PK ItemListID
FK1 ItemListID[]
FK2 ItemCode[] FK1 ItemCode

PaymentSystemsSummary Movement MerchandiseCode Movement

PK PaymentSystemsProductCode PK,FK1 MerchandiseCode

Figure 4: Merchandise Data Model

POSBO_ImplementationGuide Page 16 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
5.3 Fuel
The fuel data model defines fuel grades, the composition of those grades from inventoried products delivered to the site,
and the location of products in tanks. It also allows for reporting by grade, product, and tank.

FuelPosition

PK FuelPositionID

FK1 PriceTierCode TankProduct Tank Movement

FK1 ServiceLevelCode
PK TankID PK,FK1 TankID
FK1 TimeTierCode
FK2 TankID
TankIDHigh
FK1 FuelGradeID

FuelGradeAxis Movement

PK,FK1 FuelGradeID
FuelGrade FK1 PriceTierCode
PK FuelGradeID FK1 ServiceLevelCode
PK PriceTierCode FK1 TimeTierCode
TaxStrategy MerchandiseCode
PK ServiceLevelCode
PK TaxStrategyID PK MerchandiseCode PK TimeTierCode
FuelProduct FuelProduct Movement
FK1 TaxStrategyID FK1 FuelProductID
FuelProductIDHigh PK FuelProductID PK,FK1 FuelProductID
FK2 MerchandiseCode
FK3 TaxStrategyID

FuelGrade Movement

FuelPriceChange PK,FK1 FuelGradeID

PK,FK1 PriceTierCode FK1 PriceTierCode

PK,FK1 ServiceLevelCode FK1 ServiceLevelCode
PK,FK1 TimeTierCode FK1 TimeTierCode
PK,FK1 FuelGradeID

Figure 5: Fuel Data Model

POSBO_ImplementationGuide Page 17 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
5.4 Taxes
The tax data model has TaxIncludes and TaxLevel items that define individual tax categories for computing taxes and
reporting taxes collected, as well as sales in taxable categories. Tax Strategy provides a way to associate multiple TaxLevel
and TaxIncludes elements to a single item or merchandise code.

TaxIncludes

PK TaxLevelID

TaxLevel Movement TaxLevel TaxStrategy

PK,FK1 TaxLevelID PK TaxLevelID PK TaxStrategyID

FK1,FK2 TaxLevelID

Figure 6: Taxes Data Model

POSBO_ImplementationGuide Page 18 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
5.5 Tender
The current version of the Specification does not allow for tender configuration, but it does support reporting sales by
tender, as well as tender related batch reports.

Tender TenderSummary Movement

PK Tender PK,FK1 Tender

BatchSummaryAxis Movement

PK BatchID

BatchSummary Movementl

PK BatchID

Figure 7: Tender Data Model

POSBO_ImplementationGuide Page 19 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
5.6 Workforce
The workforce data model allows the Back Office System to configure information about employees and to assign tasks
and schedules. This version of the Specification does not currently support any reporting for workforce.

Schedule Task Employee

PK EmployeeID

Figure 8: Workforce Data Model

POSBO_ImplementationGuide Page 20 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
5.7 POS Journal
The POS Journal records events from the POS on a periodic basis (e.g., shift, day, other). Sales, refunds, voids are primary
events, with financial and other events completing the available data.

JournalReport

JournalHeader SaleEvent RefundEvent VoidEvent FinancialEvent MaintenanceAuditEvent OtherEvent

See Financial See Other

Event Detail Event Detail
TransactionDetail

TransactionLine TransactionSummary

Figure 9: POS Journal Data Model

POSBO_ImplementationGuide Page 21 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
FinancialEventDetail

BatchDetail CheckCashDetail DrawerLoanDetail DriveOffDetail PayInDetail PayOutDetail PriceOverrideDetail SafeDropDetail SafeLoanDetail PumpTestDetail

Figure 10: POS Journal Financial Event Detail

OtherEvent

DayDetail DrawerAlarmDetail RegisterDetail AlertDetail SecurityOverrideDetail MemoDetail

CashierDetail FuelPriceChangeDetail ItemExemptionDetail ShiftDetail TimeClockDetail DispenserStatusDetail RestrictedSalesDetail NosaleDetail TerminalStatusDetail

Figure 11: POS Journal Other Event Detail

POSBO_ImplementationGuide Page 22 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
6 Data Specification

6.1 Configuration
Information on configuration is exchanged using the NAXML-PBIMaintenance schema
or using the PBIConfiguration wrapper around the maintenance schema. Top-level
elements found in the schemas are described in the following sections.

6.1.1 QUAID
Using the PBIConfiguration schema, a sending system or device (e.g., Back Office) can
query and update the receiving system (e.g., Point-of-Sale) via one of the following
methods, known as "QUAID": Query, Update, Add, Initialize, and Delete. Additional
information on how QUAID is used can be found in section 8.2.1 QUAID.

6.1.2 Site
The site configuration data sets are used to exchange fundamental information
regarding a specific retail site, which has certain fundamental characteristics (e.g., ID,
name, address, phone number) that should be consistent across all components of the
retailer’s business information system. The site configuration data sets include:

SiteMaintenance: Site maintenance is used to set basic operational parameters often

in common between the POS and the Back Office.

6.1.3 Merchandise
The merchandise data sets are used to identify and categorize products for sale by a
retail site, as well as to configure mix/match and combo deals. The merchandise data
sets include:

ComboMaintenance: Combo Maintenance (CBT) contains data elements that need to

be sent from the Back Office to the POS to properly link and price items sold in a
“combo.” A combo is defined as “selling a specific set of items at a promotional price,”
e.g., one drink, one sandwich, and one bag of chips sold together.

ItemListMaintenance: Item List Maintenance (ILT) contains data elements that

need to be sent from the Back Office to the POS to designate items for inclusion in either
the mix-match or combo-pricing scheme.

ItemMaintenance: Item Maintenance (ITT) contains data elements that need to be

sent from the Back Office to the POS to enable an item to be sold at the POS terminal.
Additional information on items can be found in section 8.2.3 Merchandise.
POSBO_ImplementationGuide Page 23 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
MerchandiseCodeMaintenance: Merchandise Code Maintenance (MCT) contains
data elements that need to be sent from the Back Office to the POS to properly maintain
the status of all items at the merchandise code level. Merchandise code is most
commonly known as department or category. Additional information on merchandise
codes can be found in section 8.2.3 Merchandise.

MixMatchMaintenance: Mix-Match Maintenance (MMT) contains data elements that

need to be sent from the Back Office to the POS to properly identify and price items in a
mix-match scheme. Mix-Match is defined as “selling one or more items at a
promotional price, where the items are generally of the same product or family of
products and generally have the same retail price” (e.g., two bottles of soda for $2,
normal selling price $1.25 each).

6.1.4 Fuel
The fuel data sets are used to identify and map fuel grades, fuel positions, and tank
products, as well as to establish tank parameters and tier pricing. The fuel data sets
include:

FuelGradeMaintenance: Fuel Grade Maintenance (FGT) contains data elements

that need to be sent from the Back Office to the POS to enable a fuel grade to be sold at
the POS terminal. Additional information on fuel grades can be found in section 8.2.4
Fuel.

FuelPriceMaintenance: Fuel Price Maintenance (FPT) contains data elements that

need to be sent from the Back Office to the POS to set the price for a fuel grade.

FuelPositionMaintenance: Fuel Position Maintenance (FOT) contains data

elements that need to be sent from the Back Office to the POS to establish fuel grade
selling information for each fueling position, including time tier, price tier, and service
level.

FuelProductMaintenance: Fuel Product Maintenance (FPT) contains data elements

that need to be sent from the Back Office to the POS to enable a fuel product to be
inventoried at the retail site and tied to the fuel grades sold at the POS
terminal/dispenser. Additional information on fuel grades can be found in section 8.2.4
Fuel.

TankProductMaintenance: Tank Product Maintenance (TPT) contains data

elements that need to be sent from the Back Office to the POS to establish the
configuration of the retail site’s tanks, including product contained in the tank, tank

POSBO_ImplementationGuide Page 24 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
capacity and other tank vital statistics. The elements contained in this table would
generally be sent to the POS as part of an initial configuration.

6.1.5 Taxes
The taxes data sets are used to configure taxes that must be collected by the POS. The
taxes data sets include:

TaxIncludesMaintenance: Deprecated in 3.4.4; New implementations

should not use this element. Tax Includes Maintenance (TIT) contains data
elements that need to be sent from the Back Office to the POS to establish taxing
authority and calculation sequence for each tax level. The elements contained in this
table would generally be sent to the POS as part of an initial configuration.

TaxLevelMaintenance: Tax Level Maintenance (TLT) contains data elements that

need to be sent from the Back Office to the POS to establish tax information per tax
level, including a tax table to be used for breakpoints, tax rate, etc. The elements
contained in this table would generally be sent to the POS as part of an initial
configuration.

TaxStrategyMaintenance: Tax Strategy Maintenance (TST) contains data elements

that need to be sent from the Back Office to the POS to maintain methods and
algorithms for the application of tax to items/merchandise code/fuel grade. TaxStrategy
items contain one or more references to TaxLevel or TaxIncludes items. TaxStrategy is
used, for example, to associate, a MerchandiseCode with one or more taxes.

6.1.6 Workforce
The workforce data sets are used to configure and manage information about
employees. The workforce data sets include:

EmployeeInformationMaintenance: Employee information maintenance makes

basic human resources information available to the POS from the Back Office.

ScheduleMaintenance: Schedule Maintenance is used by the Back Office to notify

the POS regarding the employee schedules for the period.

TaskMaintenance: Task Maintenance is designed to allow the Back Office to notify

the POS regarding tasks to be performed at the retail site on a daily, shift, or cashier
basis.

POSBO_ImplementationGuide Page 25 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
6.2 Reporting
The following sections document the top-level elements found in the NAXML-
PBIMovement schema.

6.2.1 Site
The miscellaneous summary report provides summary information from the site not
found in other movement reports. The miscellaneous summary data sets include:

MiscellaneousSummaryMovement: Miscellaneous Summary Movement (MSM)

contains data elements the POS needs to send to the Back Office to report “non-sale”
summary level detail for transactions not handled by other datasets (e.g., vendor
payouts).

6.2.2 Merchandise
The merchandise reports provide information about sales of specific merchandise, as
well as combos and mix/match specific sales data. The merchandise reporting data sets
include:

ComboSalesMovement: Combo Sales Movement (CBM) reports sales of “combo

sales.” A combo is a type of promotion involving the purchase of a specific set of items
for a single, typically discounted price. For example, a retailer may offer a special lower
price for a sandwich, drink and chips when purchased together as opposed to the
combined regular price for all three individual items when they are sold
separately. Combo Sales Movement reports the number and quantity of sales for all
combos sold within the report period. The report also includes information about the
discounts provided and the actual items sold within the combo list.

ItemSalesMovement: Item Sales Movement (ISM) reports sales, refunds, and voids
grouped by each individual unique item sold within the reporting period. ISM reports
list the number sold and sales amount for each unique item and sums the discounts
applied for each item.

MerchandiseCodeMovement: Merchandise Code Movement (MCM) reports sales,

refunds, and voids grouped by the Merchandise Code associated with each sale in the
reporting period. Item, Combo, and Fuel sales are included in these totals based on
their respective Merchandise Codes. Open Department level sales are also included,
based on the Merchandise Codes assigned to the sale.

PaymentSystemsProductCodeMovement: Payment Systems Product Code

Movement (PSPCM) groups and totals (adds) sales amounts, sales quantities, and
POSBO_ImplementationGuide Page 26 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
transaction counts within the reporting period by the Conexxus Payment System
Product Code.

6.2.3 Fuel
The fuel reports provide information about sales of specific fuel grades or inventoried
products, as well as tank inventory information. The fuel reporting data sets include:

FuelGradeMovement: Fuel Grade Movement (FGM) reports sales totals grouped by

fuel grade. Depending on implementation, these reports may be broken down further
by price tier, service level, or time tier.

FuelGradeAxisMovement: Fuel Grade Movement (FGM) by Axis contains data

elements the POS needs to send to the Back Office to report fuel grade level sales. The
data set implies that all fuel grade sales are included in the Merchandise Code
Movement table (MCM) at the summary level. Depending on implementation, it can be
either in total or by grade. All grades are reported (e.g., a blending site that combines
two products into three grades would report sales for three grades). For more
information on axis reporting, see section 8.3.4 Axis Reporting.

FuelProductMovement: Fuel Product Movement (FPM) reports the non-resettable

meter totals resulting from sales of inventoried products as delivered to the retail site.
Only inventoried products are reported (e.g., a blending site that combines two products
into three grades would report sales for two inventoried products).

TankProductMovement: Tank Product Movement (TPM) reports the fuel product

levels, water levels, fuel temperature and other data about the contents of each tank.

NAXML-FuelTankStockReport: The Fuel Tank Stock Report describes other detailed

information regarding site fuel (e.g., fuel temperature) typically reported from tank level
monitoring (TLM) equipment. It may be data reported directly from the TLM to the
Back Office or relayed via the POS.

6.2.4 Taxes
The tax report provides information about taxes collected. The taxes reporting data sets
include:

TaxLevelMovement: Tax Level Movement (TLM) contains data elements the POS
system needs to send to the Back Office to report tax collection information by tax level,
including taxable, tax exempt, and tax forgiven (e.g., food stamp program purchases)
amounts.

POSBO_ImplementationGuide Page 27 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
6.2.5 Tender
Legal tender is a medium of payment allowed by law or recognized by a legal system to
be valid for meeting a financial obligation. 1 In the United States, legal tender for retail
site payments are those payment types defined in ANSI X9.104-Part 2. The term “legal
tender” is often shortened to “tender” in retail environments. Tender reports provide
information categorized by types of financial transactions. The tender reporting data
sets include:

BatchSummaryMovement: Batch Summary Movement (BSM) contains data elements

the POS needs to send to the Back Office to report “Batch” summary level detail for all
credit/debit/ACH network authorized transactions.

TenderSummaryMovement: Tender Summary Movement (TSM) contains data

elements the POS needs to send to the Back Office to report “Tender” summary level
detail for all financial transactions.

NAXML-AutoSafeReport: The Auto Safe Report feature is separate from the rest of
the POS/BackOffice interface. The schema document for this feature is aligned with the
Movement Reports (e.g., headers). The Auto Safe Report allows for reporting of
deposits, cash or checks collected, current change funds, and other cash movement
functions. Some of these are reportable by day or by shift, or as a “snapshot” at a point
in time.

6.3 POS Journal

The POS journal report provides information about transactions and events, both
financial and non-financial. The data sets shown below are found in the JournalReport
in the NAXML-PBIJournal schema.

SaleEvent: SaleEvent describes a transaction created by the POS or outdoor payment

terminal (OPT) in which goods or services are sold to a customer. A sale typically affects
the cash drawer and inventory.

RefundEvent: RefundEvent describes a transaction in which a refund is issued to a

customer. A refund typically affects the cash draw and inventory.

VoidEvent: VoidEvent describes a transaction in which the cashier voided a

transaction. Because the transaction was never finalized, the cash drawer and inventory
will not be affected.

1 Definition from Wikipedia (http://www.wikipedia.org)

POSBO_ImplementationGuide Page 28 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
FinancialEvent: FinancialEvent describes a transaction that affects the financial or
inventory totals for the reporting period, but is not a sale, refund, or void. Examples of
FinancialEvents include, but are not limited to, check cashing, drawer loan, drive-off,
pay-in, pay-out, price override, safe drop, safe loan, and pump tests.

OtherEvent: OtherEvent describes non-financial transactions that do not affect the

cash drawer or inventory. These types of events can capture details about the system
when a status change or other triggering event occurs. Examples of OtherEvents
include, but are not limited to, fuel price change, item exemption, drawer alarm, alert,
security override, memo, no sale, period close, and terminal status change.

MaintenanceAuditEvent: MaintenanceAuditEvent can be used to add markers to

the journal to allow for “store countdown” or other internal audit events.

7 Internationalization
The Point of Sale/Back Office Specification supports internationalization through the
use of currency codes and site language preference. The SiteDetails complex
element under SiteMaintenance has two attributes, DefaultCurrencyCode and
SecondaryCurrencyCode, to specify currency. See section 8.4.8 Foreign Currency
for further discussion of foreign currency. Two attributes, DefaultLanguageCode
and SecondaryLanguageCode, are used to specify site language preference.
Internationalized support using SiteDetails is implementation dependent.

8 Implementation Details

8.1 Working Samples

In an effort to promote the best possible interoperability, starting with V3.6, the
POS/BO Committee has generated actual working examples for various types of
reporting and journal events. The xml examples are prescriptive in the use of elements
and attributes for the example, but they are not so prescriptive to limit other elements
and attributes as long as they have not been deprecated.

In addition to the examples, there is an XSLT supplied which allows “transactions” to be

balanced against the published reconciliation. Each example balances against the
published reconciliation using the XSLT provided.

POSBO_ImplementationGuide Page 29 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
Where appropriate, references to these examples are provided in the following sections.
The example xml files and style sheets can be downloaded from the Conexxus website as
part of the current version of the Specification. The example zip file is packed

8.2 Configuration
Configuration data contains the necessary parameters to setup the POS system. The
Back Office System typically maintains a copy of the configuration data.

8.2.1 QUAID
A sending system or device (e.g., Back Office) can query and update the receiving system
(e.g., POS) via one of the following methods, known as "QUAID": Query, Update, Add,
Initialize, or Delete. Previously supported maintenance patterns (e.g., non-QUAID) are
still supported, but may be deprecated in a future release of this Specification.

The QUAID methods allow a sending system to interact with data sets using:

• Query: Request transmission of specified data set(s) from the receiving system;
• Update: Request the update of one or more existing members of specified data
set(s);
• Add: Request insertion or update of one or more existing members of specified
data set(s);
• Initialize: Replace existing contents of specified data set(s) with a new collection
of zero or more members; and
• Delete: Request the removal of one or more existing members of specified data
set(s).

Regardless of the order in which configuration changes are provided in an instance

document, the receiving system is responsible for processing the instance document
contents in whatever order is necessary to preserve relational integrity.

8.2.1.1 Nillability
Nillability in the context of a W3C XML Schema 1.0 indicates that the value of the
element is not set (e.g., there is no value for this element). Per the Conexxus Design
Rules for XML, two cases in which nillability may be useful are:

• When the sending system cannot provide a value for a required element, the use
of nil for that element may be appropriate, as determined by the schema
designers; or
• When the sending system must indicate that the value of an optional element has
changed from a non-null value to null, the use of nil is appropriate.

POSBO_ImplementationGuide Page 30 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
For QUAID, this translates into the following table:

Field is nillable Field is not nillable

When Element is Required
Sending system has no
Nil *Invalid*
support for element.
Present OK
Not Present *Invalid*
When Element is Optional (Initialize)
Nil Set field null (or default) *Invalid*
Present Update field
Not Present Set field null (or default)
When Element is Optional (Update and Add)
Sending system must
indicate a change from a
Nil *Invalid*
non-null value to a null for
an element
Present Update field
Sending system must update parent element containing
Not Present an optional element whose value is unchanged, and
therefore omits the optional element.

8.2.1.2 Query Configuration Data

Typically, configuration data flows from the Back Office to the POS, but the
Specification also supports the ability to query configuration data from the POS. This
might be useful if the Back Office was added or replaced after the POS had already been
configured. It might also be used by the Back Office to collect any configuration changes
that might have been made directly at the POS.

To query configuration data from the POS, a query document using the NAXML-
ConfigurationRequest element from the NAXML-PBIConfiguration schema should
be created. The Query element should be used, choosing the desired query content
element and populating sub-elements and attributes as appropriate. The guid attribute
should be populated by creating a Globally Unique Identifier (GUID) for each new
request.

The granularity of the available configuration data is dependent on the POS

implementation. Populated elements and attributes in the request act as a filter on the
requested data. If there is nothing populated in the query type, the POS should return
all available data of the requested query type.

POSBO_ImplementationGuide Page 31 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
For example, to query the configuration information for all merchandise codes, see
example XML file Configuration/01-Query-MCTDetail.xml.

For example, to query the configuration information for merchandise code 9999, see
example XML file Configuration/01-Query-MCTDetail-specific.xml.

8.2.1.3 Update Configuration Data

The update operation allows individual fields of an existing POS record to be updated.

To update configuration data to the POS, an update document using the NAXML-
ConfigurationRequest element from the NAXML-PBIConfiguration schema should
be created. The Update element under ConfigurationGroup should be used,
choosing the desired update content element and populating sub-elements and
attributes as appropriate. The guid attribute should be populated by creating a GUID
for each new request.

For example, to update merchandise code 9999, see example XML file
Configuration/02-Update-MCTDetail.xml.

8.2.1.4 Add Configuration Data

The add operation allows new records to be added to (or to replace) existing records at
the POS.

To add configuration data to the POS, an add document using the NAXML-
ConfigurationRequest element from the NAXML-PBIConfiguration schema should
be created. The Add element under ConfigurationGroup should be used, choosing
the desired add content element and populating sub-elements and attributes as
appropriate. The guid attribute should be populated by creating a GUID for each new
request.

For example, to add merchandise code 9999, see example XML file
Configuration/03-Add-MCTDetail.xml.

8.2.1.5 Initialize Configuration Data

The initialize operation will cause existing records at the POS to be removed and can
provide new records to be added.

To send initialization configuration data to the POS, an initialize document using the
NAXML-ConfigurationRequest element from the NAXML-PBIConfiguration
schema should be created. The Initialize element should be used, choosing the

POSBO_ImplementationGuide Page 32 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
desired initialize content element and populating sub-elements and attributes for any
records desired. Sending an initialize data set document that contains no records
removes any existing such records at the POS. The guid attribute should be populated
by creating a GUID for each new request.

For example, to initialize (clear) the merchandise code records and add merchandise
code 9999, see example XML file Configuration/04-Initialize-
MCTDetail.xml.

8.2.1.6 Delete Configuration Data

The delete operation will remove designated records at the POS.

To delete configuration data from the POS, a delete document using the NAXML-
ConfigurationRequest element from the NAXML-PBIConfiguration schema should
be created. The Delete element under ConfigurationGroup should be used,
choosing the desired delete content element and populating sub-elements and attributes
as appropriate. When deleting a record, the only parameter necessary is the record key
information. The guid attribute should be populated by creating a GUID for each new
request.

For example, to delete merchandise code 9999, see example XML file
Configuration/05-Delete-MCTDetail.xml.

8.2.2 Site
Data defined in the site configuration set is used across the system.

8.2.2.1 Site Data Set

Site information is normally a single record containing information useful to the POS.
More than one record may be used if different POS positions need to access different
data. Identifying which POS positions might use which SiteID is out of scope for this
Specification. Site data is found in the SiteDetail complex element under
SiteMaintenance.

8.2.2.2 Reason Code Data Set

ReasonCode maintenance allows reason codes outside of the built-in capabilities of the
Specification by using explicit extensions. While it has always been possible to use new
values in reports dynamically, this maintenance capability allows reason codes to be
defined for use in advance.

The maintenance function takes:

POSBO_ImplementationGuide Page 33 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
• A new reason code – up to 40 characters;
• A reason code type – one of the existing reason code categories; and
• A description of the reason code.

8.2.3 Merchandise
Merchandise describes the goods and services available for sale at a site. The
Specification does not define a list of merchandise or category codes; it only provides a
way to load the codes into the POS.

8.2.3.1 Item Codes

ItemCode is the element that contains information that identifies an item for sale at a
POS. The components of an ItemCode are the POSCode itself (a string of digits), the
POSCodeFormat (e.g., UPC, EAN, PLU), and a POSCodeModifier. During a
transaction, these codes are normally inputted through the scanner with optional
cashier input (the modifier). The ItemCode may or may not be the same as the SKU
“stock keeping unit” (or inventory item identifier) that the Back Office uses to track
inventory and deliveries.

The checkDigit attribute on POSCodeFormat is optional, with allowed values of

absent or present. If the attribute is not there, it makes no statement as to whether
the check digit is there or not. If the value is absent, then there is no check digit. If the
value is present, then the consumer of the data will need to make assumptions with
the POSCodeFormat value. For example, UPCA is 12 digits with a check digit (11
without).

By definition, a Global Trade Identification Number (GTIN) must include the check
digit. When using barcode numbers formatted as a GTIN, the POSCodeFormat
format attribute must contain a value of gtin, and the checkDigit attribute must
contain a value of present.

For other barcode number formats, the checkDigit attribute SHOULD be provided,
with the appropriate value to indicate whether a barcode check digit is provided. The
inclusion of barcode check digits is strongly recommended to ensure the integrity of the
data, as well as provide consistency with other formats.

8.2.3.2 Item Lists

An item list is a sequence of one or more item codes, merchandise codes, or group codes
(a predefined set). Item lists are useful for defining such things as mix/match, combo,
and other sets of items for sale.
POSBO_ImplementationGuide Page 34 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
8.2.3.3 Merchandise Codes
A merchandise code, depending on the system, may also be known as a department or a
category code. A merchandise code represents a subset of items for sale so that sales
and other activity for the subset can be tracked and reported. Merchandise codes are
described in the MCTDetail complex element under
MerchandiseCodeMaintenance.

The MerchandiseCode field (i.e., the id for the data set) is composite in order to
support the hierarchical nature of the data set. The level field, if present, indicates
that the id is composite, and, a “1” represents the top level. By convention, if no
hierarchy is used, level should not be indicated for any MerchandiseCode. The
delimiter is a period (“.”) between the subfields of the ID, and the level number must
match the number of delimited fields. Each subfield of the MerchandiseCode must be
at least one and up to 16 numeric digits.

Example 1

MerchandiseCode Level Description

1000 1 Top level code 1000
1000.45 2 Subcode 45 under top level 1000
2000 1 Top level code 2000
Subcode 45 under top level 2000 (not the
2000.45 2 same as 1000.45)
2000.45.3 2 ERROR - level number doesn't match

Example 2

MerchandiseCode Level Description

1000 Single level code 1000
2000 Single level code
3000 Single level code 3000
ERROR - merchandise codes should be defined
4000 1 either with levels or not, no mixing.

POSBO_ImplementationGuide Page 35 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
For example, to set up a hierarchical Merchandise Code for Maintenance, see example
XML file Maintenance/01-MerchandiseCodeMaint.xml.

8.2.3.4 Payment System Product Codes

Payment system product codes (which are different from merchandise codes) define
petroleum and merchandise products and services using specific three-digit codes.
These codes can be sent to the payment network acquiring the transaction and/or
issuing host to identify products or product categories in an individual transaction or
sale. Host payment systems, along with payment processing vendors, are encouraged to
adapt their systems to utilize these codes to facilitate the use of industry standard
product definitions.

Prior to revision 3.5, the Specification allowed any payment system product code to be
passed between the Back Office and the POS. Starting in version 3.5, the schema will
enforce defined three-digit product codes. The payment system product codes
specification and corresponding schema
(NAXMLCore-PaymentSystemProductCodes.xsd) can be found on the Conexxus web
site (http://www.conexxus.org) in the standards area. These Payment System Product
Codes are also maintained by Conexxus as part of ANSI X9.104-Part 2, the US national
standard for transaction messaging between a POS and an acquiring host.

To support systems that do not conform to the defined three-digit codes, the POS/Back
Office schema will allow any two, four, or five-digit code. For example:

• 22 IS allowed, it is 2 digits;
• 434 IS allowed, it is defined in the Payment System Product Codes schema
explicitly;
• 435 is NOT allowed, it is not defined as a three-digit code in the Payment System
Product Codes schema;
• 1111 IS allowed, it is 4 digits; and
• 56789 IS allowed, it is 5 digits.

8.2.3.5 Controlled Substances

Sites may be required to transmit personal consumer data to a central agency when
controlled substances, such as over the counter drugs containing ephedrine, are sold.
To allow the POS to determine if any of these types of substances are included in a
transaction, the type attribute in a SalesRestrictFlag in SalesRestriction in
ITTDetail (for items) or MCTDetail (for departments) must be set to enumerated
value controlledSubstance.

POSBO_ImplementationGuide Page 36 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
8.2.4 Fuel
Fuel grade configuration can be sent from a Back Office to a POS using the fuel grade
maintenance data set (FGT). FGT contains the necessary configuration data to setup a
sellable grade of fuel, including whether or not the grade is derived from the blending of
two inventoried products, the blend percentage, tank assignments, the network or
payment system product code, taxes, price, etc. If a grade is changed from a blended
grade back to a single inventoried product, the optional FuelProductIDHigh element
should be set to nil.

Fuel Price Maintenance (FPM) may be used when only grade prices are sent (without
the corresponding complete grade configuration data.)

The paymentSystemProductCode attribute of fuelStockIDSimpleType is

intended to be a Conexxus Payment Systems Product Code which is a three-digit
numeric string. While not enforced explicitly, creators of Fuel Grade maintenance
documents should limit the paymentSystemProductCode attribute to one of the
Conexxus Payment System product codes.

8.2.5 Taxes
Tax Strategies are described in the TSTDetail complex element under
TaxStrategyMaintenance. Tax Levels are described in the TLTDetail complex
element under TaxLevelMaintenance. In addition to the xml examples shown inline
below, there are two example XML file available in the downloads: Maintenance/02-
TaxLevelMaint.xml and Maintenance/03-TaxStrategyMaint.xml.

A Tax Strategy defines a set of taxes, wherein each tax is identified by a unique tax level
ID, that are to be combined together under a unique tax strategy ID. The tax strategy ID
is then assigned to the items, merchandise codes, and fuel grades to which the set of
taxes defined in the strategy must be applied at the time of sale. By assigning a tax
strategy to a merchandise code, all the items that are associated with that merchandise
code are taxed by all the tax levels associated with that tax strategy. When an item is
associated directly with a tax strategy code and indirectly through a merchandise code,
the direct item-to-tax strategy association takes precedence over the indirect association
though a merchandise code. Since tax strategies are linked to tax levels (e.g., state, local,
city taxes), this link is also used to influence how the calculation of one tax might affect
the calculation of subsequent taxes. An example of this latter situation occurs when a
tax is calculated based on the results of a previously calculated tax (tax on tax).

POSBO_ImplementationGuide Page 37 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
While Tax Strategy determines which taxes apply for a merchandise code, fuel grade, or
item, a tax level defines exactly how a specific tax is to be calculated.

Figure 12: Tax Levels

8.2.5.1 Calculation of Taxes

Taxes are calculated based on the type of tax specified in the Tax Level, one of:

• Percentage Taxes (SalesAmount * TaxRate);

• Fixed Amount (Specific amount per unit sold); or
• Tax table (Different rates based on amount of sale).

A “TaxSpecialRule” can be defined at the POS to calculate taxes in cases where the other
methods are not adequate to handle the calculation.

8.2.5.2 Tax Tables

A tax breakpoint table is used to calculate taxes based on a table that arbitrarily
designates a set of taxes to charge based on a corresponding set of sales amounts.

There are two types of tax breakpoint tables:

• The Tax Simple Breakpoint Table - This table contains a list of sales values and
their respective tax amounts. No repeating pattern is assumed and there is an
option to set the tax to be charged as a percentage of the transaction total once
the sales amount increases beyond the range of the specified table; and
• The Tax Repeating Breakpoint Table - This table is designed to handle a list of
sales values with respective taxes when a repeating pattern exists. This data
structure is capable of modeling the repeating nature of these tax tables and will
remove the need for tedious data entry.

POSBO_ImplementationGuide Page 38 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
8.2.5.2.1 Tax Simple Breakpoint Table
A typical tax table might resemble the following:

Sales Amount Tax

.13 .01
.21 .02
.30 .03
.39 .04
Charge 10% for any amount above those shown in the tax table.

This is an example of a simple breakpoint table.

Note that the rangeEnd defines the upper limit where the taxAmount applies.

Beyond the scope of the table, the tax is calculated at 10 percent of the sale amount.

There is an assumption that the sales amount and respective taxes are in ascending
order. The rangeEnd defines the top range for a tax. An amount between the
preceding entry and this one is taxed by this entry.

POSBO_ImplementationGuide Page 39 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
8.2.5.2.2 Tax Repeating Breakpoint Table
If a tax table is large and follows a repeating pattern, then the
TaxRepeatingBreakpointTable may be more appropriate. For example, this is a
tax table from the Florida sales tax.

Sales From To Tax Sales Range Tax Increment

(To-From) (Current-Previous)
0.10 0.16 0.01 .06 .01
0.17 0.33 0.02 .16 .01
0.34 0.50 0.03 .16 .01
0.51 0.66 0.04 .15 .01
0.67 0.83 0.05 .16 .01
0.84 1.09 0.06 .25 .01
1.10 1.16 0.07 .06 .01
1.17 1.33 0.08 .16 .01
1.34 1.50 0.09 .16 .01
1.51 1.66 0.10 .15 .01
1.67 1.83 0.11 .16 .01
1.84 2.09 0.12 .25 .01
2.10 2.16 0.13 .06 .01

Note that a pattern is forming, starting with sales of 0.10:

• 6 cents is added to the starting sales amount to calculate the ending range of the
sales amount with a corresponding 1-cent addition to the tax;
• 16 cents is added with a 1-cent addition to the tax;
• 16 cents is added with a 1-cent addition to the tax;
• 15 cents is added with a 1-cent addition to the tax;
• 16 cents is added with a 1-cent addition to the tax; and
• 25 cents is added with a 1-cent addition to the tax.

Then the pattern repeats indefinitely.

POSBO_ImplementationGuide Page 40 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
The following XML sample demonstrates how to use the TaxRepeatingBreakpointTable
feature to model the above tax table:

The amount added for each range of sales is specified via taxableIncrement attribute
on the TaxRepeatingBreakpointEntry element. In this example, the incremental
tax is consistent throughout the table (1 cent) and is specified via the TaxIncrement
element. If instead the tax increases by a variable rate, then an additional
taxIncrement attribute can be included on any TaxRepeatingBreakpointEntry
to specify the new tax increment. For example:

. <TaxRepeatingBreakpointEntry taxableIncrement="0.16" taxIncrement=”.02”/>

The repeating pattern is specified within Repeat. If the first entries in a tax table are
not part of a repeating pattern, it is necessary to specify additional
TaxRepeatingBreakpointEntry elements outside of Repeat.

POSBO_ImplementationGuide Page 41 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
8.2.5.3 Special Rule Tax
Sometimes, there is no way for the Back Office to determine the tax ahead of the
transaction. For example, taxes on a donut may vary depending on the other items in
the transaction. To handle these situations, the Back Office can designate a rule by
name that the POS executes to calculate tax based on these “special situations.”

<TaxSpecialRule>name=”DonutRule”</TaxSpecialRule>

8.2.5.4 Tax Included in Price

Sometimes, the tax on an item is already included in the price of the item. The
TaxStrategyTaxLevelID designated in a tax strategy includes an optional attribute:

includedInPrice indicates that this particular tax is already included in the

price of the item or fuel sold.

8.2.5.5 Tax on Tax

Taxes may also be calculated based on the result of previous tax calculations. To
accomplish this, the TaxStrategyTaxLevelID designated in a tax strategy includes
an optional attribute:

taxOnTaxGroup indicates the sequence of calculations. If the attribute is not

present, a sequence of 0 is assumed.

A tax strategy indicates all the taxes to be applied for a particular item or merchandise
sale. The taxOnTaxGroup creates a sequence of tax calculations. Tax levels with the
same taxOnTaxGroup are calculated from the same base amount and the combined
result becomes the new base amount for subsequent calculations.

For example, a tax strategy may be defined as follows:

<TSTDetail>
<TaxStrategyID>1</TaxStrategyID>
<TaxStrategyTaxLevelID taxOnTaxGroup=”1”>7</TaxStrategyTaxLevelID>
<TaxStrategyTaxLevelID taxOnTaxGroup=”2”>8</TaxStrategyTaxLevelID>
</TSTDetail>
This indicates that tax level 7 should be applied first. The resulting amount becomes the
new base amount on which tax level 8 should be applied. If tax level 7 is 9% and tax
level 8 is 12%, tax calculation for a $1 item sold is as follows:

Calculation 1: $1.00 * .09 = $0.09 tax, for a new base amount of $1.09; and
Calculation 2: $1.09 * .12 = $0.13 tax, for a total due of $1.22.

POSBO_ImplementationGuide Page 42 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
If two entries with exist within the same taxOnTaxGroup, then both of those
calculations become the basis for the subsequent calculation. For example, a second tax
strategy may be as follows:

This indicates that tax levels 6 and 7 should be applied first. The combined resulting
amount becomes the new base amount on which tax level 8 should be applied. If tax
level 6 is 5%, tax level 7 is 9%, and tax level 8 is 12%, tax calculation for a $1 item sold is
as follows:

Calculation 1a: $1.00 * .05 = $0.05 tax;

Calculation 1b: $1.00 * .09 = $0.09 tax;
Calculation 1 results: $0.14 combined total tax for a new base amount of $1.14;
and then
Calculation 2: $1.14 * .12 = 0.1368, rounded to $0.14 tax, for a total due of $1.28.

8.2.5.6 Tax Holidays

Some states and local jurisdictions offer customers tax-free periods. Qualifying items
sold during a tax-free period are not charged the corresponding state or local tax. To
accomplish this scenario:

(Warning: Save the existing setup so you can revert back to the normal tax situation
after the tax-free period is over.)

1. Review the tax strategies for the items that are designated as tax-free;
2. Set up alternate tax detail records with a zero tax rate for those taxes that are zero
during the period in question;
3. Create a new set of tax strategies that replace the existing taxes with references to
the zero tax rate taxes for each tax that is to be tax-free;
4. Upload the new tax strategies and the tax detail records to the POS; and
5. To revert back to the normal taxable situation, send the POS the original tax
strategies that point back to the regular tax rates.

POSBO_ImplementationGuide Page 43 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
8.2.5.7 Tax Exempt Sales
If tax regulations require keeping track of non-taxable sales as well as taxable sales,
designating a tax strategy that refers to a tax level with a zero rate allows tracking of a
tax-exempt situation.

8.2.6 Workforce
Workforce encompasses:

• The Employee data set (used to identify employees working at a given retail site);
• The Task data set (required work to be done in the retail site); and
• The Schedule data set (used to assign Employees to Tasks at a specific time).

The purpose of Workforce is to enable simple but effective sharing of data from the Back
Office to the POS, so that, for example, the POS can communicate with employees about
work required.

8.3 Reporting
When a reporting period is “closed” on the POS, a group of summary reports is
produced. The following sections define how these reports are produced and requested
and the information they may contain.

8.3.1 Reporting Conventions

Currently, the Specification does not prescribe any specific way to retrieve reports,
although using a document to request reports conforming to the “report schema”
(NAXML-PBIReports.xsd) is an option. Sets of reports that have the following fields in
common – BusinessDate, PrimaryReportPeriod@interval, and (BeginDate,
BeginTime) - should report POS activity from the same time period.

As a general rule, Movement reports (as defined in NAXML-PBIMovement.xsd) should

express amount values aligned with those defined in the balancing rules for the
NAXML-POSJournal.xsd documents. For example, if SaleAmount within a
RefundEvent is negative in the Journal, the same negative amount should be in the
movement report (e.g. Miscellaneous Summary Movement) as well.

Extensions (either vendor feature or merchant requirement) should follow the

guidelines in section 8.5 Extensions. For an example XML file that uses extensions, see
POS-Journal/01.01.999_SaleEvent_MdseSale_ByItem-Taxable-
WithExtensions.xml.

POSBO_ImplementationGuide Page 44 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
8.3.2 Reporting Process and Periods
The Specification utilizes the following definitions for reporting purposes.

Transaction – A set of transactions can be retrieved using the NAXML-ReportRequest

complex element from the NAXML-PBIReports schema. PrimaryReportPeriod
should be populated with zero or more of the following additional constraints:
BeginDate/BeginTime, EndDate/EndTime, or BusinessDate. The Specification
does not report querying a given transaction number, though some implementations
may support it.

Day Period – A day period is an accounting period, normally equivalent to a single

business day, for which the POS shall produce a close report. Store personnel, can
however, perform a "day close" process earlier than normal, either accidentally or to
accommodate an unusual event, such as a full store audit, a temporary closure to replace
equipment, robbery, or other cause. In addition, store personnel may neglect to
perform a day close, resulting in the inclusion of transactions for what would normally
be two or more business days within a single day period. This may occur due to an
oversight or in cases where the retailer's policy is to prohibit a day close by personnel
other than the manager (e.g., on weekends).

Shift Period – A shift period is an accounting period that is a proper subset of the day
period, for which the POS provides a close report encompassing all POS transaction
conducted within the retail site.

Cashier Period – A cashier period is an accounting period (not necessarily a proper

subset of the Day Period or Shift Period) encompassing all transactions performed by a
given cashier for a given till (cash drawer), from the time the cashier opens the till to the
time the cashier closes that same till. The cashier period may or may not fall entirely
within a single shift period, but ideally should fall entirely within a day period. Cashier
period reports are typically used to facilitate performance analysis, loss prevention
analysis and cash over/short accountability.

Daypart – A daypart is a reporting period (not necessarily a proper subset of the Day
Period) defined as a fixed timespan (e.g., 06:00 to 06:30) for which the retailer gathers
summary reporting for operational, rather than accounting purposes. Daypart reports
are typically taken at fixed intervals throughout the day, and are commonly used within
the quick service restaurant industry to assist in production planning and labor
scheduling. A daypart may fall across the boundary between day, shift, or cashier
reports and therefore are not typically reconciled to accounting reports. A daypart

POSBO_ImplementationGuide Page 45 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
report may encompass all activity within the retail site, or it may reflect only activity for
a specific sales area (e.g., the front counter, drive-thru window).

Week Period, Month Period, Year Period – these accounting periods are normally
equivalent to a week, month or year for which the POS shall produce a close report. Like
a day period and for the same reasons listed for a day period, a close can occur earlier or
later either on purpose or by accident or neglect.

One of these period types should be used in the interval attribute of

PrimaryReportPeriod in either the JournalHeader (for journal reports) or the
MovementHeader (for movement reports).

At the point in time when a reporting period is closed (e.g., end of day), all POS activity
(e.g., transactions, sales, tenders, income/expense, other metrics) and physical
measurements (e.g., manually entered merchandise counts, fuel tank readings, pump
totalizers) that are related to a business day are recorded and summarized to provide
reporting for:

• Assets (Fuel, Merchandise, Receivables, Cash);

• Liabilities (Sales taxes, employee timecards);
• Income (from sales of merchandise, fuel, and/or services);
• Expenses; and
• Metrics (e.g., key performance indicators, loss prevention indicators).

Note: if a BusinessDate element appears in the JournalHeader, it must match all

other BusinessDate elements in the journal document.

8.3.3 Movement Report Request

To query movement report information from the POS, a query document using the
NAXML-ReportRequest element from the NAXML-PBIReports schema should be
created. The MovementQuery element should be used, populating sub-elements and
attributes as appropriate. The guid attribute should be populated by creating a GUID
for each new request.

The granularity of the available report data is dependent on the POS implementation.
Populated elements and attributes in the request act as a filter on the requested data. If
there is nothing populated in the query type, the POS should return all available data of
the requested query type.

POSBO_ImplementationGuide Page 46 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
For example, to query the configuration information for a primary report period of
"2014-01-01", see example XML file Reports/01-MovementQuery-
PrimaryReportPeriod-Day.xml. Note that additional selector elements such as
nax:BusinessDate might be necessary.

<?xml version="1.0" encoding="UTF-8"?>

<nax:NAXML-ReportRequest version="3.6" xmlns:nax="http://www.naxml.org/POSBO/Vocabulary/2003-
10-16">
<nax:MovementQuery guid="3F2504E0-4F89-11D3-9A0C-0305E82C3301">
<nax:PrimaryReportPeriod interval="day">2014-08-13</nax:PrimaryReportPeriod>
</nax:MovementQuery>
</nax:NAXML-ReportRequest>

8.3.4 Axis Reporting

Version 3.5 and later of the Specification provides a way for the POS to partition report
information so that the Back Office can conveniently process totals grouped together in
various predetermined ways by the POS (i.e., along a given axis or several axes) within a
single report document. A benefit of grouping related totals by axis is the count and
amount fields (i.e., the payload) can be processed in a uniform manner by the Back
Office, regardless of which grouping is being examined.

Axes are orthogonal to each other. Each axis is optional. One or more attributes, one
for each axis, on each “totals” element combine to provide different views of the same
data. There is no requirement that the sending system provide these views.

The POS may choose to provide totals elements (payload records) using varying degrees
of reporting granularity. This would be useful in those cases where the Back Office
might desire to "sum up" such elements.

The sum of totals elements identified by a specific axis value should be equal to the total
contained in a totals element that does not identify a specific such axis value. In other
words, when a given axis attribute is omitted (i.e., not provided) by the POS, the sum of
the totals elements is assumed to equal to the amount across all possible values of the
omitted axis.

For example, in FuelGradeAxisMovement, a specific FGMAxisDetail element (for a

given FuelGradeID) might have a set of FGMAxisSalesTotals elements, each
qualified by a fuelPositionID attribute. However, if the POS elected to not provide
the fuelPositionID attribute, the set of FGMAxisSalesTotals would be
considered to include the sum across all fuel positions.

POSBO_ImplementationGuide Page 47 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
For a minimum level of functionality, POS systems should provide "summary" totals
elements (where no axis attribute is used). To provide more detail (better granularity),
additional totals elements should be provided using as many axes (axis attributes) as is
feasible.

Consumers of totals data should expect to encounter multiple unique sets of axis
attributes (axes) underneath a given report element. To avoid overstating results, the
Back Office should group records from each unique set of axes together for separate
processing.

At present, the following reports are available using axes:

• Payment Network Batch Summary Report; and

• Fuel Grade Movement Report.

8.3.4.1 Fuel Axis Promotion Reporting

The Fuel Axis report is designed to allow easy reporting by a single axis (i.e., by fuel
position or by service level) or by a rollup using multiple axes. Using one or more axes
allows the requester to further qualify the FuelGradeAxisMovement. Starting in V3.6
of the Specification, promotionID is an available axis for the report.

See example XML file Movement/04-FGMAxis-ByGrade.xml for an example of a

report using fuel axis. The example illustrates fuel grade movement totals reported in a
single report document, grouped in one of the following different ways:

• by fuelPositionID alone;
• by priceTierCode and fuelPositionID; or
• by priceTierCode, serviceLevelCode, fuelPositionID, and
promotionID.

Starting in V3.6, this report has been improved by adding the following fields to the
body of the report:

• PromotionTotal;
• RefundPromotionTotal;
• DispenserPromotionTotal; and
• RefundDispenserPromotionTotal.

POSBO_ImplementationGuide Page 48 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
8.3.5 Site
“Site” refers to data that applies to an entire retail site that may need to be configured
from the Back Office (e.g., address, phone number, default and secondary currency, and
other properties which can be exchanged as “name/value” pairs.)

8.3.5.1 Miscellaneous Summary

The miscellaneous summary report is a way to report key performance indicators or
other summary information that does not fit neatly into merchandise reporting.
Miscellaneous summary provides an organized method for exchanging this data.

8.3.6 Merchandise
The ItemSalesMovement (ISM) and MerchandiseCodeMovement (MCM) reports
provide a way to present sales activity of merchandise during a given reporting period.
Items may be sold at a discounted price as a result of one or more discounts or
promotions (e.g., combo/mix-match or an employee or loyalty discount). The ISM and
MSM list the different combinations of applied adjustments, while still reporting the
sales information only once.

To achieve this efficiency, ItemSalesMovement and MerchandiseCodeMovement

reports contain PromotionTotal and DiscountTotal elements. PromotionTotal
contains an amount, quantity, count, and reason for the specific promotion.
DiscountTotal contains the same fields for discount. Both DiscountTotal and
PromotionTotal may appear more than once for a specific piece of merchandise,
depending on the adjustments that have been applied.

8.3.6.1 Item Sales Movement Report

The ItemSalesMovement (ISM) report lists sales, refunds, and voids grouped by the
individual unique items sold within the reporting period. Each unique item is
represented within the report by an ISMDetail element. The ISMDetail element
provides descriptive information within its ItemCode, ItemID, Description, and
MerchandiseCode sub-elements.

Additionally, the ISMDetail element also provides sales, discount, and promotions
information within its ISMSellPriceSummary, ISMReasonSummary, and
ISMSalesTotal sub-elements.

8.3.6.2 Merchandise Code Movement Report

The MerchandiseCodeMovement (MCM) report lists sales, refunds, and voids
grouped by the MerchandiseCode associated with each sale within the reporting
POSBO_ImplementationGuide Page 49 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
period. Item, combo, fuel, and open department sales are included in these totals based
on their respective merchandise codes.

Each merchandise code is represented within the report by an MCMDetail element.

The MCMDetail element provides descriptive information within its
MerchandiseCode and MerchandiseCodeDescription sub-elements.

Additionally, the MCMDetail element also contains one MCMSalesTotals sub-

element, which contains all sales and discount information for the merchandise code
department or group.

For each merchandise code, the data returned in MCMSalesTotals will be the sum of
the aggregate values for all sales items having that merchandise code value.

8.3.6.3 Discounted Refunds in ISM and MCM Reports

It is possible for a refund transaction to have one or more price reductions as a result of
discounts, promotions, or price overrides. Because the DiscountTotal and
PromotionTotal elements contain only non-negative values, the ability to capture
these values separately is supported in Version 3.6 and later of the schemas.

The ISMSalesTotal and MCMSalesTotal elements also have

RefundDiscountTotal and RefundPromotionTotal child sub-elements.
Additionally, the ISMSalesTotal also has a RefundPriceOverrideTotal sub-
element.

8.3.6.4 Reporting Voided Refunds

Starting in V3.6 of the schemas, the movement reports were updated to allow reporting
of refunds subsequently voided. Sales total elements VoidRefundAmount,
VoidRefundCount, and VoidRefundQuantity representing voided refund lines
have been added to ISMSalesTotals, MCMSalesTotals, TSMSalesTotals,
CBMSalesTotals, and FGMSalesTotalsType. These changes affect the following
reports:

• Merchandise Sales Movement;

• Tender Summary Movement;
• Combo Sales Movement; and
• FuelGradeMovement (including FuelAxis Movement).

8.3.7.1 Fuel Grade Movement Report

A Fuel Grade Movement (FGM) reports fuel sales by grades. The POS may provide
FGM information for a given fuel grade ID using one or more of the following axes:

• priceTierCode;
• serviceLevelCode;
• timeTierCode;
• fuelPositionID;
• outside;
• reason;
• actualSellPrice;
• tenderCode;
• tenderSubCode; and
• discountID.

See example XML file Movement/01-FGM-ByGrade.xml or Movement/01a-FGM-

ByGrade.xmlfor examples of fuel grade movement totals reports.

8.3.7.2 Fuel Discounting

Fuel discounts may be applied before dispensing (roll back the price per unit at the
dispenser) or they may be applied after the fuel is fully dispensed. Note: specific
implementations of fuel discounting may conflict with third party intellectual property
rights, requiring that the implementer obtain a license to use the intellectual property.

The FGM report provides the following elements to report discounts, which allows
determination of whether they are included or excluded from dispenser meter totals.

DispenserDiscountCount and DispenserDiscountVolume: The number of

transactions and the total volume of fuel to which discounts were applied with a reduced
price at the dispenser.

DiscountCount and DiscountVolume: The number of transactions and the total

volume of fuel to which discounts were applied with no reduced price at the dispenser.

8.3.8 Taxes
A Tax Level Movement (TLM) report includes one or more TLMDetail records, which
hold information about the tax collected and other tax related information required by

POSBO_ImplementationGuide Page 51 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
tax authorities (e.g., tax exempt sales amounts). Each record contains tax totals by tax
level.

The TLM report may be optionally grouped by a “context axis” that may report totals by
any supported combination of the following:

• Cashier or Employee Number;

• Register;
• Till;
• Merchandise Code; or
• Tax Strategy.

Note: None of the above groupings are required and one, two, three, or any or all
groupings can be specified.

The report produced includes a Movement header that defines the period, a
SalesMovementHeader that defines the level of detail (see context axis above) for the
report and the subsequent Tax Level (TLM) buckets for the period specified.

If no SalesmovementHeader is provided, the assumption is that the report is for the

entire period as described in the Movement Header.

See example XML file Movement/05-TLM-standard.xml for an example tax level

movement report at the site level.

8.3.9 Tender
A Batch Summary Movement (BSM) report includes one or more BSMDetail records,
which identify the batch number and status and provide other information about the
batch (count, amount, etc.)

The Batch Summary Axis Movement report is a more comprehensive way to report on
credit host batch closes. Because of security changes by some payment hosts, processing
vendors, or retailers, as well as using more terminal IDs at the sites, the existing Batch
Summary Movement report is insufficient for accurate reporting. The existing
BSMSalesTotals only uses the batch number as an identifier. A site may connect to
multiple hosts and may have multiple network terminal IDs at the site. Therefore, the
unique identifier is actually a concatenation of host Id, terminal Id and batch number.

The axis report allows the receiving system to query the Batch Summary Axis Movement
report by payment card type or loyalty program. The typical report will contain multiple
BSMAxisTotals elements. If the card type identifier or loyalty program identifier are

POSBO_ImplementationGuide Page 52 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
omitted, the total is for ALL batches in this reporting period. If either the card type or
loyalty program is specified, the total is for the specified card type or loyalty program.
Typically, the card type and loyalty program would not both be specified for one
BSMAxisTotals element. A BSMAxisTotals record refers to a report period and is
one of two kinds: either it identifies a specific card type, or it does not identify a specific
card type (in which case it is a summary). In other words, the sum of the
BSMAxisTotals records that identify a specific card type should be equal to the total
contained in the BSMAxisTotals record, which does not identify a specific card type
(i.e., the summary). . The same is true for the loyalty program. The attributes of
BSMAxisTotals provide different views of the same data. There is no requirement
that the sending system provide these views.

For an example Batch Summary Movement Report, see example XML file
Movement/06-BSMAxis.xml.

8.4 Journal
The POS Journal is the transaction journal from a retail site for a period of time. It
reports POS activity on a transaction-by-transaction and event-by-event basis. It
includes all financial and non-financial transactions created by the POS, including the
OPT. The Journal presents, in chronological order, the series of actions performed by
the POS, including but not limited to, sales transactions, refunds, voids, price changes,
shift closes, and cashier logins. For a typical journal document format, see example
XML file POS-Journal/99-JournalHeaderExample.xml.

Individual journal schema elements do not present card security concerns. However,
when combined with other sensitive data (e.g. PAN data, track data, ICC data), journal
schema elements may become sensitive data. Therefore, implementers must be careful
to conform to all applicable card security requirements (e.g. PCI).

Within a LineItem, ActualSalesPrice SHOULD reflect the impact of Discount

and Promotion elements. Multiplying ActualSalesPrice by SalesQuantity
MUST equal SalesAmount. Taxes, if reported at the line level, MAY sum across other
LineItem elements into one of the TransactionTax elements reported at the
transaction level (in its own TransactionLine). All other fields in a given LineItem
are informative only.

8.4.1 Journal Conventions

The recommended use of the following elements is that they should appear in their own
TransactionLine element.:

POSBO_ImplementationGuide Page 53 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
• ItemLine;
• FuelPrepayLine;
• FuelLine;
• MerchandiseCodeLine;
• MoneyOrderLine; and
• TransactionTax.

Any other elements may appear in the same TransactionLine to further describe the
TransactionLine.

Where Discount and Promotion are used within journal elements (e.g., ItemLine,
MerchandiseCodeLine) they should be considered to be informative, indicating how
much of a separately provided DiscountLine was allocated to the parent element (e.g.,
ItemLine, MerchandiseCodeLine) WITHOUT altering the value of SalesAmount.

ActualSalesPrice should reflect the impact of Discount and Promotion elements.

Starting with Version 3.6 of the schemas, the correct signing of various fields in the
POS-Journal are defined. The sign of these fields must be correct in order for the
balancing rules for POS-Journal transactions to be accurate. For instance, in a
RefundEvent, SalesAmount(s) must be negative, and the
TransactionTotalGrossAmount (which includes those items) should also be
negative. The examples show proper use of these various fields.

The rules for balancing the transaction require that certain arithmetic operations on one
set of fields in the transaction result in equivalence with other fields. In POS-Journal
parlance, fields included in these relationships are “normative” and all other fields are
“informative.” For instance, SalesAmount is normative, whereas
ActualSalesPrice is informative.

The complete rules are set forth below. Any transaction document can be tested with a
stylesheet constructed to test the validity of the values in terms of balancing. That
stylesheet is “sumissue440.xslt” and is named for the Mantis Issue that the committee
used to determine the summing rules. Starting with Version 3.6, the stylesheet can be
downloaded from the Conexxus website as part of the current version of the
Specification.

POSBO_ImplementationGuide Page 54 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
Balancing Rules:
TransactionSummary/TransactionTotalGrossAmount =
sum(TransactionDetailGroup/TransactionLine/ItemLine/SalesAmount) +
sum(TransactionDetailGroup/TransactionLine/FeeLine/FeeAmount) +
sum(TransactionDetailGroup/TransactionLine/MerchandiseCodeLine/SalesAmount) +
sum(TransactionDetailGroup/TransactionLine/FuelPrepayLine/SalesAmount) +
sum(TransactionDetailGroup/TransactionLine/FuelLine/SalesAmount) +
sum(TransactionDetailGroup/TransactionLine/MoneyOrderLine/MoneyOrderFaceAmount) +
sum(TransactionDetailGroup/TransactionLine/MoneyOrderLine/MoneyOrderFeeCollected)

Add promos/discounts (these will be negative in the normal case) back for TransactionTotalNetAmount:
TransactionSummary/TransactionTotalNetAmount =
TransactionSummary/TransactionTotalGrossAmount +
sum(TransactionDetailGroup/TransactionLine/PromotionReward/PromotionRewardGroup/DiscountAmo
unt) + sum(TransactionDetailGroup/TransactionLine/DiscountLine/Discount/DiscountAmount) +
sum(TransactionDetailGroup/TransactionLine/Loyalty/DiscountAmount)

TransactionSummary/TransactionTotalTaxExemptAmount =
sum(TransactionDetailGroup/TransactionLine/TransactionTax)/TaxExemptAmount

TransactionSummary/TransactionTotalTaxNetAmount =
sum(TransactionDetailGroup/TransactionLine/TransactionTax/TaxCollectedAmount) +
sum(TransactionDetailGroup/TransactionLine/TransactionTax/TaxRefundedAmount)

Then, there are two ways to compute TransactionSummary/TransactionTotalGrandAmount, proving the

transaction balances:

POSBO_ImplementationGuide Page 55 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
TransactionSummary/TransactionTotalGrandAmount = TransactionTotalNetAmount +
TransactionTotalTaxNetAmount

TransactionSummary/TransactionTotalGrandAmount =
sum(TransactionDetailGroup/TransactionLine/TenderInfo/TenderAmount) +
sum(TransactionDetailGroup/TransactionLine/RoundingAmount) // RoundingAmount should correct for
currency amount rounding errors

8.4.2.1 Promotion
A promotion is defined as a time-based reduction in price that may be based on
purchase of specific items, use of specific payment, etc. (e.g., Combo, mix match).

ItemLine, MerchandiseCodeLine and FuelLine elements each have an optional

Promotion element. This is information only as the parent element has already been
adjusted.

The Promotion element includes:

• PromotionID – A unique identifier for this promotion;

• PromotionReason – The reason for this promotion; and
• PromotionAmount – The amount of reduction in price applied. This will be
negative if the reduction is associated with a sale or positive if the reduction is
associated with a refund.

8.4.2.2 Discount
A discount is defined as a reduction of price that is discretionary based at time of
purchase (e.g., senior discount)

ItemLine, MerchandiseCodeLine and FuelLine elements each have an optional

Discount element. This is information only as the parent element has already been
adjusted.

The Discount element includes:

• DiscountAmount - The amount reduction in price applied. This will be

negative if the reduction is associated with a sale or positive if the reduction is
associated with a refund;
• DiscountReason - The reason for the discount; and
• TransactionTax (optional) - Any tax implications applied to the discount.

8.4.2.3 DiscountLine
This is the recommended method of representing a “discount”. This is an adjustment to
the first sibling of the TransactionLine or if in a separate TransactionLine the
“event” itself. As opposed to Promotion and Discount, which have their effects
already factored into the item amount, the DiscountLine has an effect on transaction
totals. Use discount structures to describe the actual discount caused by promotions in

POSBO_ImplementationGuide Page 57 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
the transaction and in the discount structure, use DiscountReason to indicate the
promotion that caused this discount.

The DiscountLine element includes:

• DiscountAmount: The amount reduction in price applied (negative value if

reduction going to customer/positive if reduction from customer (refund))
• DiscountReason: The reason for the discount.
• TransactionTax (optional): Any tax implications applied to the discount.

8.4.2.4 Loyalty
Loyalty is defined as a reduction in price authorized by the presence of a card, token,
barcode, chip, etc. that is connected to a loyalty program authorized by the
store/site/unit.

The Loyalty element may appear as a sibling of ItemLine, MerchandiseCodeLine,

FuelPrepayLine and FuelLine or in a TransactionLine of its own. This is an
adjustment to the first sibling of the TransactionLine or, if in a separate
TransactionLine,to the “event” itself.

The Loyalty element includes:

• AccountInfo: Used to capture appropriate data;

• LoyaltyTransactionID: Unique ID returned by the loyalty processor for the
transaction;
• LoyaltyProgramName: Unique name of the loyalty program;
• A choice of:
o DiscountAmount: amount by which the item or ticket was reduced;
o RedeemedPointsQuantity: the number of points redeemed in a points
based loyalty program; or
o EarnedPointsQuantity: the number of points earned in a points
based loyalty program.
• LoyaltyQuantity: The quantity for which the discount applies. A line item
may have more sales quantity associated with it than the loyalty eligible quantity;
and
• OriginalAmount: the original amount of the item before reduction in price.
For fuel transactions, this is the price per unit (PPU) prior to discounting.

8.4.3 Taxes
The TaxableSalesAmount reflects the amount on which tax should be collected for
the TransactionLine in which it appears. The TaxableSalesAmount could be
greater than the SalesAmount when taxable price reductions take place (i.e., tax needs
to be collected on the original amount before any reductions). For example: the
POSBO_ImplementationGuide Page 58 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
RegularSellPrice is 13.49, SellPrice is 12.99 (0.50 taxable manufacturer rebate
reduction) SalesAmount is 12.99 TaxableSalesAmount is 13.49. Whether tax
should be collected on the original or reduced amounts is determined by the local
jurisdiction.

Tax exempt sales amount and taxable sales amount should follow the same sign as sales
amount.

8.4.3.1 Tax Exemptions

Starting with V3.6, tax exemptions have been improved to include reasons for the
exemption. These reasons will be supplied when the cashier enters a tax-exempt sale.

For ItemTax and TransactionTax, there is now an element called

TaxExemptReason which can designate either of the following two options for a
reason:

• forResale: Sales of items intended for resale.

• forTaxExemptOrg: Sales of items to a Tax-Exempt Organization.

8.4.4 Fuel

8.4.4.1 Drive Offs

As part of the improvements to the definitions for the POS Journal, starting with V3.6
drive offs and pump tests have been given specific places they can occur in the journal.
These are:

• DriveOff: now used in the context of a SaleEvent. (Previously a

FinancialEvent.)
• PumpTest: now in the context of a FinancialEvent. (Previously treated as a
tender type.)
• DriveOffInfo: now in the context of a SaleEvent, to appear under
FuelLine.
• Starting with V3.6, DriveOffInfo includes:
• FuelGradeSalesVolume: the amount of fuel associated with the drive
off (should be a negative amount);
• FuelGradeSalesAmount: the amount in currency of the drive off
(should be a negative amount);
• LicensePlateID: the license plate identifier of the person leaving the
scene if available;
• VehicleDescription: the description of the vehicle;
• VehicleColor: the color of the vehicle;
• VehicleType: the model or type of the vehicle;
POSBO_ImplementationGuide Page 59 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
• AuthorizingCashierID: cashier assigned to the transaction; and
• LinkedTransactionInfo: link to another transaction associated with
this one.

8.4.5 Linked Items and Fees

Linked Items and Fees are a way to sell multiple items, including services, and/or fees,
at the same time. Examples are container deposits, environmental fees, additional
items as kits, etc... When the main item is rung up the linked item(s) are automatically
added to the transaction line in the ticket. Linked items appear as siblings of the main
item in the same TransactionLine. Linked items can be represented as FeeLine or
ItemLine elements, and must appear after the main item.

8.4.6 Pay In and Pay Out

Pay ins and pay outs are miscellaneous cash payments into or out of the cash drawer
that are not safe drops or safe loans (e.g., payment on a house account, cash payment for
services rendered). The POS records these events for inclusion in the Journal Report.
PayInDetail and PayOutDetail may be used (dependent on POS implementation)
in TransactionLine elements contained in in RefundEvent, SaleEvent, or
VoidEvent.

To implement PayInDetail and PayOutDetail:

1. Use the CustomerID element to identify the source or target of the transaction;
and
2. Create an 'Extension' type defined as substitutable for the
TransactionLineExtension to contain "PayInDetail" and/or
"PayOutDetail”.

8.4.7 Coupons
POS systems may be able to accept the following types of coupons:

• Coupons issued by the retail site;

• Coupons issued by the same retailer chain for use at any retail location in the
chain; and
• Coupons issued by a manufacturer or service provider.

Manufacturer coupons can be validated by parsing the bar code of the coupon to extract
the family code and the manufacturer id and verifying against the familyCode in
ITTData and the manufacturer id within the scanned barcode of the item purchased.
After coupon acceptance, the POS should record, for journal reporting, data in
CouponReedemed as follows:
POSBO_ImplementationGuide Page 60 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
• bar code of the coupon in RedeemedCouponID;
• manufacturer id in PrimaryCompanyPrefix;
• offer code in OfferCode; and
• expiration date in CouponExpirationDate.

8.4.8 Foreign Currency

For accurate reporting of receipt of foreign (non-domestic) currencies in the POS
journal, the SecondaryCurrencyCode in SiteDetail must be populated with the
correct exchange rate (defined in terms of the domestic country currency for the site).
This method allows the sum of the domestic currency value of all tenders to match the
sum of the other line items. The journal reports the information in TenderInfo, with
the non-domestic currency in Currency and the domestic currency in the
TenderAmount.

8.4.9 Entry Methods

Transaction information (payment or other) may be entered through many different
methods. This information is reported in the EntryMethod element, which has one
attribute, method, with a default value of scan.

The EntryMethod element can be used to describe the entry method for many types of
information, like purchased merchandise, card payments, and customer birthdate. As
such, EntryMethod can be a child element of the CardInfo, CustomerID,
FuelLine, ItemLine, ComponentItem, and TimeClockDetail elements.

8.4.10 Sale Events

Sale events describe transactions created by the POS or OPT in which goods or services
are sold to a customer. For each event, ItemLine element, child element ItemCode
describes the item. The ItemLine element can also contain an optional
ItemTypeCode child element. This element helps categorize various items available at
a store. Possible values for the ItemTypeCode include carwash, fees, fuel, etc.

The adjusted price of an item is recorded in ActualSalesPrice, while

RegularSalesPrice element contains the price found in the price book. Numerous
sale event examples can be found in the example xml files. These are named
POSJoural/xx.xx.xxx_SaleEvent_xxx.xml.

A fuel prepay transaction typically generates a sale event for the initial fuel prepay,
followed by a subsequent sale event for the fuel prepay completion. To facilitate the

POSBO_ImplementationGuide Page 61 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
linking of the two events, the LinkedTransactionInfo should be populated with
appropriate data including the OriginalTransactionID.

Stored value cards (e.g., gift cards) may be sold by and activated by the POS. During the
activation process, the card is authorized by the card issuer host. To properly report this
authorization in the sale event, the POS may supply an Authorization sub element as
part of the transaction line. For a complete example, see example XML file POS-
Journal/01.01.023_SaleEvent_GiftCard.xml.

Suspended sales transactions should have the SuspendFlag value set to “yes.” For
journal analysis with respect to totals of tenders or merchandise, if there is a
FuelPrepay line in the SaleEvent, the transaction should be included in the analysis.
Otherwise, the transaction should be excluded from the analysis.

Note: a suspended food service transaction presents unique challenges. Inventory may
be affected if the food was prepared (inventory was used) but the transaction was
suspended before the customer paid. This situation may require a void.

SaleEvent elements and RefundEvent elements can use SuspendFlag, whereas for
VoidEvent the use is deprecated. Suspended sales should contain applicable taxes
computed, even though complete tender information may not be available. For a
suspended item example, see example XML file POS-
Journal/01.01.015_SaleEvent_MdseSale_ByItem-Suspended.xml.

Some POS devices allow returns to occur in a SaleEvent and sales to occur in a
RefundEvent. To facilitate these activities, sale and return enumerations have been
added to the status attribute on the TransactionLine element. If a POS allows for
a mix of sales and returns in a SaleEvent or RefundEvent, each TransactionLine
status attribute must have an explicit value of sale or refund. The default status of
normal for a TransactionLine status attribute may only be used if all the
TransactionLine entries match the parent element for context. For a mixed sale
return example, see example XML file POS-
Journal/01.01.024_SaleEvent_MixedSaleReturn_MdseSale_ByItem-
NonTaxable.xml.

8.4.11 Refund Events

Refund events describe transactions where a refund is issued to a customer. See the
example XML documents POS-
POSBO_ImplementationGuide Page 62 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
Journal/02.01.001_RefundEvent_MdseRefund_ByItem-NonTaxable.xml
and POS-Journal/02.01.002_RefundEvent_MdseRefund_ByItem-
Taxable.xml.

8.4.12 Void Events

Void events are used to record when a cashier voids a transaction. See the example
XML document POS-Journal/03.01.001_VoidEvent_VoidSale.xml.

Reviewing void transactions for a particular reporting period of cashier provides a

mechanism to spot potential fraud activity by the cashier.

Optional attribute originalTransactionType on element VoidEvent, should be

used to specify what transaction type was actually voided when a void transaction
occurs. Valid values for the attribute are sale, refund, or financialEvent. For
example:

8.4.13 Financial Events

Financial events are transactions that affect the financial or inventory totals but are not
a sale, refund, or void.

CheckCashingDetail is used to report a check cashing transaction. The

TransactionTotalGrossAmount of the financial transaction for cashing the check
must be the sum of the cash returned to the customer, plus the
CheckCashFeeCollected. For a complete example, see POS-
Journal/04.01.01.001_FinancialEvent-CheckCashing.xml.

8.4.14 Other Events

Other events describe non-financial transactions.

At period close, if non-resettable grand totalizer information or other similar

information is desired, an OtherEvent journal entry should be created, utilizing
OtherEventExtension. For examples using the OtherEvent construct, see the
examples POS-Journal/05.01.01.*.xml
TerminalStatusDetail is used to describe a change in status of the POS (e.g., a
boot-up, a shutdown). A Back Office System could look for multiple boot-up events with
missing shut down events to indicate a potential fraud situation. For an example of this
type of event in the journal, see POS-Journal/05.01.01.003_OtherEvent-
TerminalStatus.xml.

POSBO_ImplementationGuide Page 63 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
Making change (within the same currency) is typically handled via a NoSale event,
which optionally enumerates:

• The individual who executed the NoSale (ApproverID);

• The manager who approved the NoSale if required (ApprovingManagerID);
and
• If the drawer was kept open beyond the pre-specified limit, the length of time the
NoSale kept the drawer open (AlarmDuration) may also be reported.
AlarmDuration is the total time the drawer was open.

8.4.14.1 CashierDetail and Register Detail Events

CashierDetail and RegisterDetail elements appear inside OtherEvent. They
are used to report the status of and reconcile the contents of the cashier or register
drawer. Each element contains a detailType attribute indicating what type of event it
is:

• open: reports the manually entered amounts for cash and food stamps in the
drawer when the register or cashier period is opened.
• close: reports the ECR (electronic cash register, also called POS) calculated
amounts for all methods of payment collected by the cashier or at the register.
• closeAudit: reports the manually entered amounts for all methods of payment
in the drawer. A closeAudit should precede a close, and is associated with
that close.
• audit: reports the manually entered amounts for all methods of payment in the
drawer at a given point in time and does not have a corresponding close
associated with it.

There can be one or more CashierDetail and/or RegisterDetail in a single

OtherEvent.

For an example report showing these details, see XML example file POS-
Journal/05.01.01.002_OtherEvent-CashInDrawer.xml.

8.5 Extensions
Extension points are provided in the schema so that vendors can include additional
proprietary data in their documents, and those documents can then be validated and
also used with other XML tools.

POSBO_ImplementationGuide Page 64 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
For further information on how to properly create and use extensions, consult the
Conexxus XML Guidelines as described in the reference section.

For an example XML file that uses extensions, see POS-

Journal/01.01.999_SaleEvent_MdseSale_ByItem-Taxable-
WithExtensions.xml.

Financial transaction card originated messages - Card acceptor to acquiring host

messages - Part 2: Convenience store and petroleum marketing industry.
Available at http://www.webstore.ansi.org/

ISO 3166-1:2013, ISO 3166-2:2013

ISO 3166 is the International Standard for country codes (part 1) and codes for
their subdivisions (part 2). Available at http://www.iso.org or
http://www.webstore.ansi.org/

ISO 4217:2008

ISO 4217 is the International Standard that provides codes for representation of
currencies and funds. Available at http://www.iso.org or
http://www.webstore.ansi.org/

Conexxus Design Rules for XML

Available at: http://www.conexxus.org

Payment System Product Codes

Available at: http://www.conexxus.org

XML Schema Part 1: Structures

XML Schema Part 1: Structures. Available at:

http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/

XML Schema Part 2: Data Types

XML Schema Part 2: Data Types. Available at: http://www.w3.org/TR/2001/REC-

xmlschema-2-20010502/

A.2 Non-Normative References

None

POSBO_ImplementationGuide Page 66 of 67
Copyright © 2014-2018 CONEXXUS, INC, All rights reserved. June 4, 2018
B.Glossary
Term Definition
Axis or A method of processing report totals grouped together in various
Axis predetermined ways. The allowed axes for a given report will vary
Reporting by the report type. Any individual axis is optional.

GUID Globally Unique Identifier

NACS National Association of Convenience Stores

OPT Outdoor Payment Terminal

POS Point-of-Sale

Retail Site A retail site or store is a physical location where products and
services are offered for sale to the public.

XML eXtensible Markup Language

Otkug Creo11000
No ratings yet
Otkug Creo11000
692 pages
Mediant Software SBC Users Manual Ver 74
No ratings yet
Mediant Software SBC Users Manual Ver 74
1,655 pages
ARC300 B2CCommerceArchitect Part 4 Monitoring & Troubleshooting
No ratings yet
ARC300 B2CCommerceArchitect Part 4 Monitoring & Troubleshooting
52 pages
Soal Matematika Kelas 2 SD Bahasa Inggris
100% (2)
Soal Matematika Kelas 2 SD Bahasa Inggris
17 pages
IC Compiler™ II Functional Safety Manual
No ratings yet
IC Compiler™ II Functional Safety Manual
55 pages
FlexiBIZ PEAK With Static IP
No ratings yet
FlexiBIZ PEAK With Static IP
10 pages
CA Workload Automation CA 7® Edition - 12.0 - ENU - Configuring - 20180208 PDF
No ratings yet
CA Workload Automation CA 7® Edition - 12.0 - ENU - Configuring - 20180208 PDF
722 pages
The Geographical Discoveries of The 15th and 16th Centuries
75% (4)
The Geographical Discoveries of The 15th and 16th Centuries
2 pages
BW CallCenterSolutionGuide R230
No ratings yet
BW CallCenterSolutionGuide R230
147 pages
Gen DP Proxies ENU
No ratings yet
Gen DP Proxies ENU
238 pages
Part301 DispenserApplicationV2.32
No ratings yet
Part301 DispenserApplicationV2.32
140 pages
CAClarityPPM XML Open Gateway Developer Guide ENU
No ratings yet
CAClarityPPM XML Open Gateway Developer Guide ENU
549 pages
TPC BENCHMARK Standard Specification
No ratings yet
TPC BENCHMARK Standard Specification
271 pages
Billing Concepts
No ratings yet
Billing Concepts
160 pages
M0600 SiteSentinel 1 Controller Manual
No ratings yet
M0600 SiteSentinel 1 Controller Manual
141 pages
IEC Certification Kit: Polyspace Code Prover ISO 26262 Tool Qualification Package
No ratings yet
IEC Certification Kit: Polyspace Code Prover ISO 26262 Tool Qualification Package
37 pages
Brkcol 2356 Notes
No ratings yet
Brkcol 2356 Notes
105 pages
SNOTE Revamp Implementation Guide
No ratings yet
SNOTE Revamp Implementation Guide
5 pages
People VS. Escaño, G.R. Nos. 129756-58, January 28, 2000
No ratings yet
People VS. Escaño, G.R. Nos. 129756-58, January 28, 2000
1 page
Middle East Cost Data
100% (2)
Middle East Cost Data
124 pages
BW RfRoInterfaceSpec R230
No ratings yet
BW RfRoInterfaceSpec R230
85 pages
Plex Getting Started ENU PDF
No ratings yet
Plex Getting Started ENU PDF
140 pages
CAClarityPPM XOG DeveloperGuide ENU v13
No ratings yet
CAClarityPPM XOG DeveloperGuide ENU v13
483 pages
Trellix Data Loss Prevention DLP Datasheet Endpoint
No ratings yet
Trellix Data Loss Prevention DLP Datasheet Endpoint
2 pages
Part 3 18 IFSF POS To FEP V1 Interface Specification v1.53
No ratings yet
Part 3 18 IFSF POS To FEP V1 Interface Specification v1.53
219 pages
Maintaining and Troubleshooting Avaya Dialer
No ratings yet
Maintaining and Troubleshooting Avaya Dialer
384 pages
Change Impact and Upgrade Guide ENU
No ratings yet
Change Impact and Upgrade Guide ENU
56 pages
SAP Business Objects Process Control 10.0 Automated Monitoring Overview
No ratings yet
SAP Business Objects Process Control 10.0 Automated Monitoring Overview
70 pages
Holding On To Compliance While Adopting DevSecOps
No ratings yet
Holding On To Compliance While Adopting DevSecOps
19 pages
SoW Close Bros 125A Rec 459A CAS 459A QM 584A DX
No ratings yet
SoW Close Bros 125A Rec 459A CAS 459A QM 584A DX
23 pages
Synopsys Customer Success For D0-178C
No ratings yet
Synopsys Customer Success For D0-178C
3 pages
IMO Publication Catalogue List (June 2022)
No ratings yet
IMO Publication Catalogue List (June 2022)
17 pages
Echo Go HF
No ratings yet
Echo Go HF
15 pages
OHMS Energy's O&M Offerings: - Comprehensive O&M For MW Scale - Rooftop Solar O&M
No ratings yet
OHMS Energy's O&M Offerings: - Comprehensive O&M For MW Scale - Rooftop Solar O&M
2 pages
318 Mcqs and Answers
No ratings yet
318 Mcqs and Answers
14 pages
ProtecciónDatos SeguridadNube 2
No ratings yet
ProtecciónDatos SeguridadNube 2
20 pages
24+pancreas Pancreatitis+-+update
No ratings yet
24+pancreas Pancreatitis+-+update
27 pages
Certkitiec Ug
100% (1)
Certkitiec Ug
112 pages
Design Rules For JSON V1.0.1
No ratings yet
Design Rules For JSON V1.0.1
32 pages
Autosys EEM Implementation Guide
No ratings yet
Autosys EEM Implementation Guide
71 pages
IntegrationsBuilderGuide Integrity PTCAPIs PDF
No ratings yet
IntegrationsBuilderGuide Integrity PTCAPIs PDF
181 pages
PROD PDFs Cryp-Request - Yaml
No ratings yet
PROD PDFs Cryp-Request - Yaml
4 pages
Master Guide Sap Businessobjects Nota Fiscal Eletrônica 10.0
No ratings yet
Master Guide Sap Businessobjects Nota Fiscal Eletrônica 10.0
28 pages
CH 5 Data Communication System
No ratings yet
CH 5 Data Communication System
12 pages
Global E Waste Monitor 2014 Small
No ratings yet
Global E Waste Monitor 2014 Small
41 pages
SDLC Policy 2022
No ratings yet
SDLC Policy 2022
3 pages
Resumen Economia
No ratings yet
Resumen Economia
10 pages
SEIU Local 73 Members' Lawsuit Against SEIU International Over Trusteeship: 12-14-2017
No ratings yet
SEIU Local 73 Members' Lawsuit Against SEIU International Over Trusteeship: 12-14-2017
8 pages
Defensics Fuzz Testing
No ratings yet
Defensics Fuzz Testing
2 pages
Deployment of A Centralised Platform 1
No ratings yet
Deployment of A Centralised Platform 1
1 page
Vocaprep Casebook
100% (1)
Vocaprep Casebook
260 pages
Weinbender A Goat For Azazel
No ratings yet
Weinbender A Goat For Azazel
12 pages
Kymlicka - The Ethics of Inarticulacy
No ratings yet
Kymlicka - The Ethics of Inarticulacy
29 pages
DX 1053 DeveloperGuide en
No ratings yet
DX 1053 DeveloperGuide en
91 pages
IFSF LON Schnittstellenwandler en
No ratings yet
IFSF LON Schnittstellenwandler en
16 pages
PROD PDFs Pre-Compliance-Csid - Yaml
No ratings yet
PROD PDFs Pre-Compliance-Csid - Yaml
4 pages
Ababil
No ratings yet
Ababil
4 pages
Mellanox OFED Linux Release Notes 3 4-1 0 0 0
No ratings yet
Mellanox OFED Linux Release Notes 3 4-1 0 0 0
66 pages
Invoice
No ratings yet
Invoice
1 page
Inbound 4943681093051450141
No ratings yet
Inbound 4943681093051450141
2 pages
Practice Test Questions Downloaded From FILIPINO NURSES CENTRAL
100% (1)
Practice Test Questions Downloaded From FILIPINO NURSES CENTRAL
4 pages
CA ClarityPPM Integration Guide ENU
No ratings yet
CA ClarityPPM Integration Guide ENU
553 pages
Accounting 101 Sample Exercises
No ratings yet
Accounting 101 Sample Exercises
12 pages
Group 3 Module 10
No ratings yet
Group 3 Module 10
20 pages
Devnetf
No ratings yet
Devnetf
61 pages
Certified Sarbanes-Oxley Expert (CSOE)
No ratings yet
Certified Sarbanes-Oxley Expert (CSOE)
41 pages
ARM CCIX SW Developers Guide Release Version 1.0 PDF
No ratings yet
ARM CCIX SW Developers Guide Release Version 1.0 PDF
138 pages
PARLIAMENTARIANS TAX DIRECTORY 2014Dt10042015
No ratings yet
PARLIAMENTARIANS TAX DIRECTORY 2014Dt10042015
29 pages
George Zimmerman
No ratings yet
George Zimmerman
2 pages
Law Relating To Electronic Voyeurism in India Eyes Behind The Mirror
No ratings yet
Law Relating To Electronic Voyeurism in India Eyes Behind The Mirror
4 pages
Pronano Engineering Supplies - Drugs and Alcohol Policy - DA-01
No ratings yet
Pronano Engineering Supplies - Drugs and Alcohol Policy - DA-01
3 pages
Ag Econ Q and A
No ratings yet
Ag Econ Q and A
3 pages
PSS 5000 ForecourtController ENG 80540601
No ratings yet
PSS 5000 ForecourtController ENG 80540601
4 pages
ACME Solar Holdings LTD - IPO Note
No ratings yet
ACME Solar Holdings LTD - IPO Note
9 pages
Introduction To Educational Administration A Module: June 2008
No ratings yet
Introduction To Educational Administration A Module: June 2008
44 pages
Traffic Apprehension
0% (1)
Traffic Apprehension
2 pages
Jurisdiction Over The Issue-Viajar Vs CA
No ratings yet
Jurisdiction Over The Issue-Viajar Vs CA
1 page
Prepositions of Time and Place - Article Found in
No ratings yet
Prepositions of Time and Place - Article Found in
6 pages
Sap Signavio Process Collaboration Hub Security Guide EN
No ratings yet
Sap Signavio Process Collaboration Hub Security Guide EN
14 pages
SG City-79b Price List-06-02-24
No ratings yet
SG City-79b Price List-06-02-24
1 page
DFS Fusion V3 Brochure (EN)
No ratings yet
DFS Fusion V3 Brochure (EN)
8 pages
WCAdapterGuide PDF
No ratings yet
WCAdapterGuide PDF
211 pages
Caltex (Phil.) Inc. v. Philippine Labor Organizations, Caltex Chapter
100% (1)
Caltex (Phil.) Inc. v. Philippine Labor Organizations, Caltex Chapter
3 pages
PrisMax Brochure (Prismaflex Customers)
No ratings yet
PrisMax Brochure (Prismaflex Customers)
3 pages
Chapter 40: Bowel Elimination Yoost & Crawford: Fundamentals of Nursing: Active Learning For Collaborative Practice, 2nd Edition
No ratings yet
Chapter 40: Bowel Elimination Yoost & Crawford: Fundamentals of Nursing: Active Learning For Collaborative Practice, 2nd Edition
11 pages
Narcotics
No ratings yet
Narcotics
8 pages
Api Eng
No ratings yet
Api Eng
5 pages
Gastrointestinal Quiz Answers
No ratings yet
Gastrointestinal Quiz Answers
3 pages
Opentext™ Business Center Capture For Sap Solutions: User Guide
No ratings yet
Opentext™ Business Center Capture For Sap Solutions: User Guide
36 pages
ENG101 Solved Midterm Paper
75% (4)
ENG101 Solved Midterm Paper
7 pages

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.