Technology Standards
NACS Point of Sale Back Office
Task Force Meeting Minutes
July 9, 2001
Attendees
Welcome & Introductions
Mr. Hervey opened the meeting with introductions.
He then presented the NACS policy statement against discussions of a nature
that would violate antitrust laws.
Mr. Hervey presented the agenda while waiting for
late arrivals and passed out the minutes of the previous meeting for review.
Ms. McArthur noted one error in the minutes. Mr. Hervey then passed out copies
of two draft documents prepared by the Equipment Maintenance and Alert Working
Group of the European ARTS Consortium. The EMA group is tasked by ARTS with
developing standards for the transmission of alerts by POS and other devices
used in the retail industry. Mr. Hervey recommended that the Task Force let
the EMA group complete its work on this subject before beginning work on alerts.
The group agreed to that approach.
Mr. Hervey reported that the ongoing alliance between
the NACS Technology Standards Committee and the International Forecourt Standards
Forum has been tabled pending organizational changes within the IFSF. There
has been interest expressed in reconvening the Device Integration Committee.
The Payment Systems Committee will be meeting in August for the first time this
year. Other than for the DD&R, there have been no meetings of the eB2B Committee
or its sub-committees since January.
Mr. Hervey then explained noted the recent activity
of the UCC in reorganizing around their Business Process Modeling groups. The
UCC also adopted a draft XML schema for the Global Commerce Initiative for simple
business transactions. Mr. Hervey noted the recent creation of a Point of Sale
modeling group within the UCC. An open meeting was held by the UCC in Dayton
on July 5. At that meeting, the UCC agreed to confine the scope of their POS
BMG to the grocery industry, and to cooperate with NACS and ARTS in an attempt
to consolidate data dictionaries into a single cohesive model.
IXRetail is scheduled to meet in late July to publish
some new message standards based on the ActiveStore sales transaction related
to item pricing and inventory control. IXRetail continues to make revisions
to its data dictionary, validating the decision by the NACS Technology Standards
Steering Committee to postpone any attempt to adopt the IXRetail dictionary
at this time.
Mr. Hervey stated that several states are considering
changes to the encoding of drivers license information to make age information
readable by POS devices for controlling the sale of age-restricted products.
Mr. Hervey sldo noted that proposed changes to the WIC program to implement
smart card technology are being touted as a reason for new standards. NACS position
is that the TG-23 implementation guidance developed for ISO-8583 by the Payment
Systems Committee should accommodate the WIC program changes, but there are
groups that are unwilling to adopt TG-23. This will be the subject of ongoing
discussions within the EBT/WIC X9A11 Working Group of which NACS is a member.
Mr. Hervey gave a high-level overview of pilot activities
related to the NAXML standards. Lottery has been gaining support from more states.
Georgia is almost
ready to create test documents. Connecticut
and Virginia have begun to express
interest.
The motor fuel standards are being trialed by various
vendors and trading partners. Mr. Hervey noted that he has been working with
one oil company on revisions to the Fuels Price Notification XML document.
Mr. Godwin asked for a review of the status of the
various documents produced by the NACS committee. Mr. Hervey noted that the
NAXML POS/Back Office Guidelines are currently at version 3.0, with 3.1 ready
for review by the committee and subsequent release for public comment. Mr. Godwin
noted that www.naxml.org was s bit confusing.
Mr. Hervey agreed to revise the structure of the folders to make it clearer
as to where each type of document is located.
Mr. Hervey noted that overall the NACS Technology
Standards Committee is on budget for the year. Mr. Hervey noted that the NACS
Technology committee requested additional funds in June for a review of item
level inventory methodology and to make contact with Intuit regarding the inclusion
of the NAXML guidelines in their QBXML standard, since many smaller convenience
retailers use Intuit’s Quickbooks product. The Executive Committee postponed
the item level inventory review, but approved the request for funding to study
the Intuit project. Mr. Hervey noted that the annual NACS trade show in Las
Vegas will include a new Technology track, repeating
some of the successful seminars from nacsTech 2001.
Mr. Hervey raised the question of the use of schema
vs. DTD in the ongoing development of the NAXML guidelines. He noted the relative
scarcity of publications relating to schema and their use. He recommended that
the group continue to postpone the adoption of schema until later in the fall,
at which time a working committee could be appointed to draft a schema based
on the current NAXML DTDs. The group concurred.
With the group’s agreement, a presentation was given
prepared by David Ezell at VeriFone (via conference call) on his recommendations
for the usage of schema and related XML technologies (attached).
The meeting recessed for the day at 5:30
pm.
July 10,
2001
The meeting reconvened at 9:00 AM with all attendees present.
Mr. Hervey passed out documentation for a comparison
of NAXML POS-Journal tax related structures with ActiveStore and IXRetail. Mr.
Halter identified the following issues within the NAXML POS-Journal.
- ActiveStore uses one Tax node that occurs
at both the line item and the transaction level. After some discussion, the
group decided to retain the current ItemTax and TransactionTax structures
in POS-Journal to avoid making the meaning of the tax node dependent on its
position in the document. This led to a discussion of the contents of the
NAXML ItemTax structure as compared to the NAXML TransactionTax structure.
It was noted that ItemTax does not include a TaxForgivenAmount or a TaxRefundedAmount.
TransactionTax does not contain a TaxForgivenAmount.
- ActiveStore provides a way to report taxes
that were included in the taxable amount for another tax. This requirement
is provided for in the NAXML PBIMaintenance DTD, but not in the POS-Journal
DTD. After some discussion, the group agreed that it is not necessary to report
taxable tax amounts separately from the taxable sales amounts for a given
tax level.
- ActiveStore provides the tax authority
ID in its tax node; NAXML does not. After some discussion, the group agreed
to include the TaxDescription and TaxReceiptDescription elements from the
TLTDetail node in NAXML-PBIMaintenance as optional elements in the ItemTax
and TransactionTax nodes in NAXML-POSJournal.
- ActiveStore provides a tax exemption ID
element. It was decided to add an optional TaxExemptionID element to ItemTax
and TransactionTax.
- ActiveStore provides an approver ID element
for various types of transactions. After some discussion, the group decided
to table the addition of an approver ID and reason code pending more discussion.
Mr. Halter presented a model he developed for accommodating food service. The
group discussed the model and decided to incorporate the necessary elements
into the existing ItemLine element as shown in the excerpted element definitions
below.
<?xml version='1.0' encoding='UTF-8'
?>
<!ELEMENT TransactionLine (TrayID?
, ItemLine)>
<!ELEMENT ItemLine (TentID? , SubItemLine*
, PreparationMod? , Condiment* , Part*)>
<!ELEMENT TrayID (#PCDATA)>
<!ELEMENT SubItemLine (ComponentItem
, SequenceNumber?)>
<!ELEMENT ComponentItem (ItemCode
, ItemID , Description , SerialNumber? , EntryMethod , ActualSellPrice , UnitCostPrice
, MerchandiseCode , SellingUnits , Discount? , InventoryValuePrice , Promotion?
, RegularSellPrice , PriceOverride? , SalesQuantity , SalesAmount , ItemTax?
, Condiment* , PriceModDescription? , PreparationMod? , Part*)>
<!--#DOCUMENTATION:This element
describes things like "Large, Super Size, Regular"-->
<!ELEMENT PriceModDescription (#PCDATA)>
<!--#DOCUMENTATION:This element
describes things like "well done, medium"-->
<!ELEMENT PreparationMod (#PCDATA)>
<!--#DOCUMENTATION:Best shown with
an example. The pizza is half hamburger and half pepperoni. The condiment
on one part (half in this case) would be hamburger, and the condiment on the
other part (half in this case) would be pepperoni.-->
<!ELEMENT Part (PartDescription
, Condiment+)>
<!ELEMENT Condiment (CondimentName
, CondimentID? , CondimentQuantity? , CondimentSellPrice? , CondimentAction
, PriceModDescription? , PrepMod? , SequenceNumber?)>
<!--#DOCUMENTATION:Right Half, Left
Half, Top quarter,...-->
<!ELEMENT PartDescription (#PCDATA)>
<!--#DOCUMENTATION:POS description
of the condiment - "cheese", "lettuce",...-->
<!ELEMENT CondimentName (#PCDATA)>
<!--#DOCUMENTATION:Unique ID for
this condiment-->
<!ELEMENT CondimentID (#PCDATA)>
<!--#DOCUMENTATION:Number of this
condiment on this item, i.e. 3 pieces of cheese-->
<!ELEMENT CondimentQuantity (#PCDATA)>
<!--#DOCUMENTATION:with or without
- default is with-->
<!ELEMENT CondimentAction (#PCDATA)>
<!--#DOCUMENTATION:If this element
is missing, then the price for this condiment is aggregated in the price of
the parent.-->
<!ELEMENT CondimentSellPrice (#PCDATA)>
<!--#DOCUMENTATION:Unique tent number
placed on this tray-->
<!ELEMENT TentID (#PCDATA)>
Mr. Steele presented a draft document he developed dealing with POS events.
The group decided to concentrate on events that affect cash balance in the POS
or must be reconciled with other information from the POS. After discussion
of various approaches, Mr. Wade agreed to take on the task of developing a generic
content model for other financial and non-financial events.
July 11,
2001
The task force reconvened at 8:00AM
with all attendees present. Mr. Wade presented an approach to a generic content
model for other events. After review, the group decided to treat financial
and non-financial events
It was decided to modify the content model for JournalReport as follows:
<!ELEMENT FinancialEvent (EventSequenceID
, TransactionID? , TrainingModeFlag? , CashierID , RegisterID , TillID? ,
OutsideSalesFlag? , EventStartDate , EventStartTime , EventEndDate? , EventEndTime?
, ReceiptDate? , ReceiptTime? , BusinessDate? , OfflineFlag? , SuspendFlag?
, StoreHierarchyID* , FinancialEventDetail? , FinancialEventSummary?)>
<!ELEMENT FinancialEventDetail (BatchDetail
| DrawerLoanDetail | DriveOffDetail | PayInDetail | PayOutDetail | PumpTestDetail
| SafeDetail | PriceOverrideDetail)>
<!ATTLIST FinancialEventDetail eventDetailStatus
(Cancel | Normal
| Void ) 'Normal' >
<!ELEMENT OtherEvent (EventSequenceID
, TrainingModeFlag? , CashierID? , RegisterID , TillID? , OutsideSalesFlag?
, EventStartDate , EventStartTime , EventEndDate? , EventEndTime?)>
<!ELEMENT OtherEventDetail (CashierDetail
| DayDetail | DrawerAlarmDetail | PumpStatusDetail | RegisterCloseDetail |
SecurityDetail | ShiftDetail | TimeClockDetail)>
<!ATTLIST OtherEventDetail eventDetailStatus
(Cancel | Normal
| Void ) 'Normal' >
<!ELEMENT BatchDetail (BatchNumber
, BatchType? , BatchStatus? , NetworkID? , BatchCount? , BatchAmount)>
<!ELEMENT CashierDetail (CashInDrawer?
, FoodstampsInDrawer? , Source?)>
<!ATTLIST CashierDetail detailType
(Open | Close ) #REQUIRED >
<!ELEMENT DayDetail EMPTY>
<!ATTLIST DayDetail detailType (Open
| Close ) #REQUIRED >
<!ELEMENT DrawerAlarmDetail (Duration)>
<!ELEMENT DrawerLoanDetail (Amount
, OtherDrawer? , LinkedTransactionInfo? , Tender*)>
<!ATTLIST DrawerLoanDetail loanType
(In | Out ) #REQUIRED >
<!ELEMENT OtherDrawer (CashierID
, RegisterID , TillID)>
<!ELEMENT DriveOffDetail (FuelPositionID?
, LicensePlate? , VehicleDesc? , AuthorizingCashierID? , LinkedTransactionInfo?)>
<!ELEMENT PayInDetail (Amount ,
Tender* , AccountInfo)>
<!ELEMENT PayOutDetail (Amount ,
Tender* , AccountInfo , MoneyOrderLine?)>
<!ELEMENT PriceOverrideDetail (ItemID
, PriceOverride , RegularSellPrice?)>
<!ELEMENT PumpStatusDetail (FuelPositionID?
, FuelPositionStatus)>
<!ELEMENT PumpTestDetail (FuelPositionID
, Volume , PumpTestReasonCode? , PumpTesterID? , CurrencyAmount)>
<!ELEMENT RegisterDetail EMPTY>
<!ATTLIST RegisterDetail detailType
(Open | Close ) #REQUIRED >
<!ELEMENT SafeDetail (Amount , EnvelopeID?
, DropNumber? , Tender*)>
<!ELEMENT SecurityDetail (OverridingCashierID
, OldSecurityLevel , NewSecurityID)>
<!ELEMENT ShiftDetail EMPTY>
<!ATTLIST ShiftDetail detailType (Open
| Close ) #REQUIRED >
<!ELEMENT TimeClockEvent (EmployeeNumber
, JobCode?)>
Other events suggested for inclusion are:
- A Log event to capture some free-form remark by the cashier or POS.
- An AgeRestrictedSaleEvent for quickly locating transactions that included
age-restricted products via the LinkedTransactionInfo.
- Separate time and attendance events into a separate element named TimeClockEvent
instead of as an event type under OtherEvent.
- Other device alarms, including CRINDS, cash acceptors, car wash controllers,
tank level sensors, etc.
Mr. Hervey showed a draft of a FuelTankStock report document that he derived
from a process constructed by Shell Europe. The group reviewed the document
and agreed to include it in the next version (3.1) of the guidelines as a separate
document type.
Mr. Hervey presented a method provided by Mr. Arrizza for extending the NAXML
DTDs to support proprietary vendor extensions. The group agreed to promote
the method as the preferred solution for proprietary extension of the DTDs.
Extending DTDs
This how the description of the extension method will appear in the Version
3.1 Guidelines.
The Task Force recognizes
that not all data elements have been defined nor do the tables and DTDs necessarily
comprehend all information particular vendors or retailers might require. To
allow for vendor extensions to the DTDs the Task Force has provided an extension
mechanism.
This mechanism uses an entity
with the word “Extensions” as part of its name. For example to extend the BillOfLading
content model of the NAXML-Transportation0101.dtd, an entity %BOLExtensions
is inserted into the content model at the appropriate place. The "%Extensions;"
entity is defined as an empty string. It's placed in the content model without
a preceeding comma.
For example, here is a DTD in which the extension mechanism
has been used.
<!--This is a test version of NAXML-Transportation0101Test.dtd
-->
<!—Here
the entity Extensions is declared with a whitespace between the quotation
marks.-->
<!ENTITY
% Extensions " ">
<!—This
entity is inserted in the content model but note that there is no comma following
BillOfLading+.-->
<!ELEMENT
NAXML-Transportation (TransmissionHeader, BillOfLading+ %Extensions;)>
<!ATTLIST
NAXML-Transportation version CDATA #FIXED "1.1" >
<!ELEMENT
TransmissionHeader (TransmissionId)>
<!ELEMENT
TransmissionId (#PCDATA)>
<!—A
second entitity of BOLExtensions is declared with whitespace between the quotation
marks.-->
<!ENTITY
% BOLExtensions " ">
<!—This
entity is inserted in the content model but note that there is no comma following
Equipment.-->
<!ELEMENT
BillOfLading (Equipment %BOLExtensions;)>
<!ELEMENT
Equipment (TruckId, TrailerId*)>
<!ELEMENT
TruckId (#PCDATA)>
<!ELEMENT
TrailerId (#PCDATA)>
In the following example
an xml instance document has been created that does not use the extension mechanism.
This document is both well formed and valid.
<?xml
version="1.0"?>
<!DOCTYPE
NAXML-Transportation SYSTEM "NAXML-Transportation0101Test." >
<NAXML-Transportation
version="1.1">
<TransmissionHeader>
<TransmissionId>1</TransmissionId>
</TransmissionHeader>
<BillOfLading
<Equipment>
<TruckId>21</TruckId>
<TrailerId>21</TrailerId>
</Equipment>
</BillOfLading>
</NAXML-Transportation>
In the next example an xml
instance document has been created that does uses the extension mechanism. This
document is both well formed and valid. In addition to a reference to an external
DTD this instance document contains an internal DTD that modifies declarations
in the external DTD. Note the leading commas that have been inserted on both
the %Extensions; and %BOLExtensions entities.
<?xml
version="1.0"?>
<!DOCTYPE NAXML-Transportation SYSTEM "NAXML-Transportation0101Test.dtd"
[
<!ELEMENT
VendorExtensions (MyData1,MyData2) >
<!ELEMENT
MyData1 (#PCDATA)>
<!ELEMENT
MyData2 (#PCDATA)>
<!ENTITY
% Extensions ",VendorExtensions?">
<!ELEMENT
VendorBOLExtensions (MyData3,MyData4) >
<!ELEMENT
MyData3 (#PCDATA)>
<!ELEMENT
MyData4 (#PCDATA)>
<!ENTITY
% BOLExtensions ",VendorBOLExtensions">
]
>
<NAXML-Transportation
version="1.1">
<TransmissionHeader>
<TransmissionId>1</TransmissionId>
</TransmissionHeader>
<BillOfLading>
<Equipment>
<TruckId>21</TruckId>
<TrailerId>21</TrailerId>
</Equipment>
<VendorBOLExtensions>
<MyData3/>
<MyData4/>
</VendorBOLExtensions>
</BillOfLading>
<VendorExtensions>
<MyData1/>
<MyData2/>
</VendorExtensions>
</NAXML-Transportation>
The group viewed a video of an IXRetail interoperability
demonstration made at the NRF/ARTS convention earlier in the year. Mr. Hervey
asked if a similar demo at nacs.tech would be acceptable. The group agreed that
a demo would be interesting. A discussion of alternatives led to the development
of a script that would involve ringing some sales, entering some price changes
on the back office, performing a shift close on the POS, and polling the POS
for the shift close from the back office, then sending down price changes from
the back office to the POS and ringing some more sales to show the new price.
Mr. Halter indicated that he would like to receive a POSJournal transaction
in realtime. Mr. Steele and Mr. Arrizza indicated that their back office systems
could receive a realtime transaction also. The script could be supported via
the implementation of the ItemMaintenance node in NAXML-PBIMaintenance, ItemSalesMovement
in NAXML-PBIMovement, and SaleEvent in POSJournal.
Mr. Hervey suggested that he would like to finalize
the demo script by November 1, and then send an invitation to vendors. Mr.
Hervey suggested a dress rehearsal in late February or early March. Mr. Halter
and Mr. Godwin indicated they felt a dress rehearsal that early would not be
advisable. Mr. Halter indicated that at least a full day should be allotted
prior to the demo for testing. Mr. Halter and Mr. Godwin indicated that a large
number of vendors would be very difficult to set up. Mr. Godwin indicated that
a minimum of two POS and two back office systems is required.
Mr. Hervey suggested the need for a mechanism for
vendors to communicate the portions of the NAXML guideline that they support
to other systems. After discussion, the issue was tabled for the next meeting.
The meeting adjourned at 12:20 PM.
Respectfully submitted
Bill Wade
Acting Secretary
|