About NACS
 Advertisers
 Bulletin Boards
 Directory
 Virtual Library
 Links
 Meetings Calendar
 NACS Products
 Press Releases
 PR Toolkit
 Resources
 Special Interests

 Register
 Home

 

 

 Advanced Search

 

 

 

Dixie Foodservice

 Technology Standards  

NACS Point of Sale Back Office Task Force Meeting Minutes
July 9, 2001

Attendees

Name Company Email Address
Bill Wade Professional Datasolutions, Inc. bwade@profdata.com
Fawn McArthur Wayne fawn.mcarthur@wayne.com
John Hervey NACS jhervey@cstorecentral.com
John Arrizza Marconi John.arrizza@marconi
David Godwin VeriFone David_g3@verifone.com
Laura Skop PRE Solutions lskop@presolutions.com
Peter Steele Pinnacle psteele@pinncorp.com
Richard Halter Apigent Solutions rhalter@apigent.com

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.

  1. 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.
  1. 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. 
  1. 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.
  1. ActiveStore provides a tax exemption ID element. It was decided to add an optional TaxExemptionID element to ItemTax and TransactionTax.
  1. 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

Return to top of page


National Association of Convenience Stores . 1605 King Street . Alexandria, VA 22314 . 703-684-3600 . 703-836-4564 Fax
nacs@cstorecentral.com

Copyright©2000 NACS