1. OMG Mailing List
  2. UnifiedPOS (UPOS) 1.15.1 Revision Task Force

Open Issues

  • Issues not resolved
  • Name: retail-up115-rtf
  • Issues Count: 35

Issues Summary

Key Issue Reported Fixed Disposition Status
UPOS1151-39 ElectronicValueRW, method setParameterInformation: Confusing Description UPOS 1.15 open
UPOS1151-38 ElectronicValueRW - Method retrieveResultInformation - Missing tag descriptions UPOS 1.15 open
UPOS1151-37 Point Card Reader / Writer: Wrong data type specified for property CapCardEntranceSensor UPOS 1.15 open
UPOS1151-34 Nonsensical Chapter Hierarchy UPOS 1.15 open
UPOS1151-35 Bookmarks for Most Chapters from Annex A - J Can Only Be Found in Chapter 38 Tone Indicator UPOS 1.15 open
UPOS1151-36 Point Card Reader / Writer: Wrong Section Numbers Starting at 28.4.3 UPOS 1.15 open
UPOS1151-31 Several Errors in Point Card Reader State Diagram UPOS 1.15 open
UPOS1151-32 Pin Pad: Property MinimumPINLength is read-write UPOS 1.15 open
UPOS1151-30 EVRW: _Currency_ type format makes no sense for OPOS and POS for .NET UPOS 1.15 open
UPOS1151-29 EVRW: Format of PaymentDetail unclear UPOS 1.15 open
UPOS1151-28 EVRW: Format of DailyLog unclear UPOS 1.15 open
UPOS1151-26 CAT: Format of DailyLog unclear UPOS 1.15 open
UPOS1151-27 CAT: Format of PaymentDetail unclear UPOS 1.15 open
UPOS1151-24 Electronic Journal: Value format of property MediumFreeSpace should be clarified. UPOS 1.15 open
UPOS1151-25 Electronic Journal: Value format of property MediumSize should be clarified. UPOS 1.15 open
UPOS1151-22 FiscalPrinter: The format of vatAdjustment in printRecPackageAdjustment is unclear UPOS 1.15 open
UPOS1151-23 FiscalPrinter: The format of vatAdjustment in printRecPackageAdjustmentVoid is unclear UPOS 1.15 open
UPOS1151-21 FiscalPrinter: Unclear string format for totalizer values in getTotalizer method UPOS 1.15 open
UPOS1151-19 FiscalPrinter: Unclear string format for totalizer values returned by getData UPOS 1.15 open
UPOS1151-20 FiscalPrinter: The description of currency amounts and percentage amounts is not true for OPOS and POS for .NET environments UPOS 1.15 open
UPOS1151-17 EVRW retrieveResultInformation Method did have a typo UPOS 1.15 open
UPOS1151-18 FiscalPrinter: At Least One Constant For parameter dataItem is missing at getData UPOS 1.15 open
UPOS1151-13 EVRW State Diagrams are incorrectly copy and pasted. UPOS 1.15 open
UPOS1151-14 EVRW readValue Method, transactionAccess Method, setParameterInformation Method descriptions were need to change. UPOS 1.15 open
UPOS1151-11 SmartCardRW: UML status diagram causes confusion for readData() UPOS 1.15 open
UPOS1151-10 SmartCardRW: endRemoval is not counted as chapter UPOS 1.15 open
UPOS1151-9 EVRW: DailyLog has wrong mutability constraint in the Summary section UPOS 1.15 open
UPOS1151-8 EVRW: CapDailyLog has wrong type in the Summary section UPOS 1.15 open
UPOS1151-7 EVRW: CapAuthorizePreSales is listed 2 times in the Summary section UPOS 1.15 open
UPOS1151-6 Add GS1-128 to Scanner to replace EAN-128 UPOS 1.15b2 open
UPOS1151-5 Add Dotcode to Scanner UPOS 1.15b2 open
UPOS1151-3 Aztec code misspelled in Appendix C UPOS 1.15b2 open
UPOS1151-4 Add DW Code to Scanner UPOS 1.15b2 open
UPOS1151-2 Add GS1-128 to POS Printer to replace EAN-128 UPOS 1.15b2 open
UPOS1151-1 ToneIndicator: Mismatch in access constraints between Summary and Property description sections UPOS 1.15 open

Issues Descriptions

ElectronicValueRW, method setParameterInformation: Confusing Description

  • Status: open  
  • Source: Free Software Developer ( Martin Conrad)
  • Summary:

    The description for parameter value specifies:

    If the name parameter is not recognized or not supported for the current card type, the value returned will be an empty string (““).

    but value is not specified as inout parameter.

    Three opportunities are available:

    • Make value inout: Change the Syntax line.
    • Change description for parameter value as follows:
      If the name parameter is not recognized or not supported for the current card type, it will be ignored.
    • Remove everything following "If" of the description of parameter value and add the following to the Errors section:
      Some possible values of the exception’s ErrorCode property are:
      Value - Meaning
      E_ILLEGAL - If the name parameter is not recognized or not supported for the current card type.
  • Reported: UPOS 1.15 — Tue, 13 Jun 2023 23:02 GMT
  • Updated: Tue, 9 Jul 2024 00:52 GMT
  • Attachments:

ElectronicValueRW - Method retrieveResultInformation - Missing tag descriptions

  • Status: open  
  • Source: Free Software Developer ( Martin Conrad)
  • Summary:

    There are three tables: The first one contains a list of all known tag names and a brief description of them, inclusive their types, the second table contains a list of types and their string formats and the third table contains a list of definitions and remarks for Enumerated type tags specified in the first table.
    Error 1: The tag CancelTransactionType is present in the third table, but not in the first table. A row for tag CancelTransactionType should be added to the first table. My recommendation:

    CancelTransactionType | The Enumerated number for the type of transaction cancellation.

    Error 2 and 3: For tags VOIDorRETURN and VoidTransactionType, no rows are present in the third table. In addition, no constants have been specified for the corresponding tags. I would recommend to specify two new rows in the third table:

    For VOIDorRETURN, if should contain two rows in columns "Definition" and "Remarks":

    Definition: EVRW_TAG_VR_VOID

    Remarks: Void

    and

    Definition: EVRW_TAG_VR_RETURN

    Remarks: Return

    and for tag VoidTransactionType:

    Definition: EVRW_TAG_VTT_CASH

    Remarks: Cash

    and

    Definition: EVRW_VTT_EXCHANGING_POINTS

    Remarks: Exchanging Points

    Error 4: In the second table, the format of Enumerated values is specified as "One of the text character strings defined by each tag.". It is not clear what it means: Is it the string as specified in the UPOS manual (for example, "EVRW_TAG_AS_AUTHENTICATED" for the corresponding authentication state) or is it the value of the constant EVRW_TAG_AS_AUTHENTICATED, converted to a string (which is "1" in OPOS and JavaPOS environments)? I would recommend to change the text as follows: "One of the text character strings defined by each tag. For example, if tag equals AuthenticationStatus and the status equals EVRW_TAG_AS_AUTHENTICATED, the format of the string is "EVRW_TAG_AS_AUTHENTICATED". (or ..., the format of the string is the value of the constant specified by EVRW_TAG_AS_AUTHENTICATED, e.g "1").

  • Reported: UPOS 1.15 — Sun, 11 Jun 2023 14:55 GMT
  • Updated: Tue, 9 Jul 2024 00:52 GMT
  • Attachments:

Point Card Reader / Writer: Wrong data type specified for property CapCardEntranceSensor


Nonsensical Chapter Hierarchy

  • Status: open  
  • Source: Free Software Developer ( Martin Conrad)
  • Summary:

    The chapters 1.3.6.3 - 1.3.6.19 have nothing to do with the device sharing model and are not so easy to find due to missing bookmarks.
    Probably they have been moved badly. I thing they should be moved one hierarchy above, resulting in becoming chapters 1.3.7 - 1.3.23.

  • Reported: UPOS 1.15 — Fri, 21 Apr 2023 00:46 GMT
  • Updated: Tue, 9 Jul 2024 00:52 GMT
  • Attachments:

Bookmarks for Most Chapters from Annex A - J Can Only Be Found in Chapter 38 Tone Indicator

  • Status: open  
  • Source: Free Software Developer ( Martin Conrad)
  • Summary:

    The hierarchy of most bookmarks of Annex A - J is bad: Instead of being sorted under the corresponding annex, they are located under chapter 38.
    Of cause, the chapter texts are at the correct position, but the bookmarks are not. Some duplicates are in Annex A - Annex J, but in chapter 38 are much more bookmarks.

  • Reported: UPOS 1.15 — Fri, 21 Apr 2023 01:13 GMT
  • Updated: Tue, 9 Jul 2024 00:52 GMT
  • Attachments:

Point Card Reader / Writer: Wrong Section Numbers Starting at 28.4.3


Several Errors in Point Card Reader State Diagram

  • Status: open  
  • Source: Free Software Developer ( Martin Conrad)
  • Summary:

    For the box "Card in PointCard R/W", the labeling of the DataEvent arrow (DataEventEnabled==true & error) is wrong. It must be changed to "DataEventEnabled==true & no error".
    For Writing and Printing Mode, the contents of DataEventEnabled is not relevant because DataEventEnabled controls the input model. It does not affect event handling that belongs to the output model. Therefore, the text "DataEventEnabled==true & " should be removed from the OutputCompleteEvent and (output) ErrorEvent arrow. In addition, "error" should be replaced by "no error" in case of the labeling of the OutputCompleteEvent arrow.

  • Reported: UPOS 1.15 — Sun, 26 Mar 2023 19:56 GMT
  • Updated: Tue, 9 Jul 2024 00:52 GMT
  • Attachments:

Pin Pad: Property MinimumPINLength is read-write

  • Status: open  
  • Source: Free Software Developer ( Martin Conrad)
  • Summary:

    As described in the summary and implicitly within the Remarks section of chapter 27.4.14, write support for this property is available. Therefore, the Syntax line must be changed: read-only must be replaced with read-write.

  • Reported: UPOS 1.15 — Thu, 30 Mar 2023 15:29 GMT
  • Updated: Tue, 9 Jul 2024 00:52 GMT
  • Attachments:

EVRW: _Currency_ type format makes no sense for OPOS and POS for .NET

  • Status: open  
  • Source: Free Software Developer ( Martin Conrad)
  • Summary:

    Even if this description is clear, it makes no sense to pass decimal values in a 64-bit integer format with four implicit decimals.
    For JavaPOS, this might be meaningful because type long shall be used to represent currency values with four implicit decimals.
    For OPOS, a CURRENCY is internally implemented as 64-bit integer with four implicit decimals as well, but it will be converted to a string with decimal point whenever converted to a BSTR using OLE conversion methods.
    For POS for .NET, a decimal represents currency values, and a decimal has more than 64 bit and no integer representation.
    Since currently services using the current description for data exchange via retrieveResultInformation and setParameterInformation might be present, I would recommend to specify that currency values can either be passed as 64-bit-Integer with 4 implicit decimals, converted to a string (e.g 12.34 converts to "123400") or as decimal string with decimal point (e.g. 12.34 converts to "12.34"). The decimal point in the second representation must not be omitted.
    Alternative: An additional property, e.g. CurrencyStringFormat, can be used to specify which kind of string representation shall be used. To be compatible to the current specification, the default can be EVRW_AMOUNT_AS_INTEGER. For decimal string representation, the application can set it to EVRW_AMOUNT_AS_DECIMAL. In this case, a trailing decimal point can be omitted.

  • Reported: UPOS 1.15 — Mon, 23 Jan 2023 13:13 GMT
  • Updated: Tue, 9 Jul 2024 00:52 GMT
  • Attachments:

EVRW: Format of PaymentDetail unclear

  • Status: open  
  • Source: Free Software Developer ( Martin Conrad)
  • Summary:

    It is unclear how the PaymentDetail property must be formatted: In case of several PaymentCondition values, PaymentDetail contains amount values. Due to chapter 1.3.4, the text usage of a currency value of 1234 Yen should result in a string of "12340000". Note 3 in the description of property DailyLog implies that "1234" results in a string of "1234". Since this is an amount value as well, it is unclear how the value must be stored.
    Due to the current example in note 3 of chapter 15.4.48, it should be clarified that PaymentDetail shall not use the 64-bit-integer representation of amount values to format the string. Instead, the amount values should be stored inclusive decimal point (if zero decimals are present, the decimal point can be omitted).

  • Reported: UPOS 1.15 — Mon, 23 Jan 2023 12:48 GMT
  • Updated: Tue, 9 Jul 2024 00:52 GMT
  • Attachments:

EVRW: Format of DailyLog unclear

  • Status: open  
  • Source: Free Software Developer ( Martin Conrad)
  • Summary:

    It is unclear how the DailyLog property must be formatted: Due to chapter 1.3.4, the text usage of a value of 1234 Yen, passed via currency variable amount in one of the authorize... methods, should result in a string of "12340000". Note 3 implies that "1234" results in a string of "1234".
    Due to the current example in note 3, it should be clarified that DailyLog shall not use the 64-bit-integer representation of the value to format the string. Instead, the amount value should be stored, inclusive decimal point (if zero decimals are present, the decimal point can be omitted).

  • Reported: UPOS 1.15 — Mon, 23 Jan 2023 12:44 GMT
  • Updated: Tue, 9 Jul 2024 00:52 GMT
  • Attachments:

CAT: Format of DailyLog unclear

  • Status: open  
  • Source: Free Software Developer ( Martin Conrad)
  • Summary:

    It is unclear how the DailyLog property must be formatted: Due to chapter 1.3.4, the text usage of a value of 1234 Yen, passed via currency variable amount in one of the authorize... methods, should result in a string of "12340000". Note 3 implies that "1234" results in a string of "1234".
    Due to the current example in note 3, it should be clarified that DailyLog shall not use the 64-bit-integer representation of the value to format the string. Instead, the amount value should be stored, inclusive decimal point if more than zero decimals are present.

  • Reported: UPOS 1.15 — Mon, 23 Jan 2023 12:26 GMT
  • Updated: Tue, 9 Jul 2024 00:52 GMT
  • Attachments:

CAT: Format of PaymentDetail unclear

  • Status: open  
  • Source: Free Software Developer ( Martin Conrad)
  • Summary:

    It is unclear how the PaymentDetail property must be formatted: In case of several PaymentCondition values, PaymentDetail contains amount values. Due to chapter 1.3.4, the text usage of a currency value of 1234 Yen should result in a string of "12340000". Note 3 in the description of property DailyLog implies that "1234" results in a string of "1234". Since this is an amount value as well, it is unclear how the value must be stored.
    Due to the current example in note 3 of chapter 10.4.26, it should be clarified that PaymentDetail shall not use the 64-bit-integer representation of amount values to format the string. Instead, the amount values should be stored inclusive decimal point (if zero decimals are present, the decimal point can be omitted).

  • Reported: UPOS 1.15 — Mon, 23 Jan 2023 12:38 GMT
  • Updated: Tue, 9 Jul 2024 00:52 GMT
  • Attachments:

Electronic Journal: Value format of property MediumFreeSpace should be clarified.

  • Status: open  
  • Source: Free Software Developer ( Martin Conrad)
  • Summary:

    Since currency representation may differ from the representation of the type used in a UPOS implementation, it should be clarified that the value stored in MediumFreeSpace should match the explanations in chapter A.17, B.13 and C.21.1. For JavaPOS, this means that a value of 10000000 in MediumFreeSpace means that 1000 bytes of free space remain available.

  • Reported: UPOS 1.15 — Mon, 23 Jan 2023 12:03 GMT
  • Updated: Tue, 9 Jul 2024 00:52 GMT
  • Attachments:

Electronic Journal: Value format of property MediumSize should be clarified.

  • Status: open  
  • Source: Free Software Developer ( Martin Conrad)
  • Summary:

    Since currency representation may differ from the representation of the type used in a UPOS implementation, it should be clarified that the value stored in MediumSize should match the explanations in chapter A.17, B.13 and C.21.1. For JavaPOS, this means that a value of 10000000000 in MediumSize means that the medium has a capacity of 1000000 bytes.

  • Reported: UPOS 1.15 — Mon, 23 Jan 2023 12:11 GMT
  • Updated: Tue, 9 Jul 2024 00:52 GMT
  • Attachments:

FiscalPrinter: The format of vatAdjustment in printRecPackageAdjustment is unclear

  • Status: open  
  • Source: Free Software Developer ( Martin Conrad)
  • Summary:

    Two things are unclear:

    • Amount adjustments can be given as a decimal string (e.g. a value of 12.34 as "12.34") or as described in chapter 1.3.4 for type currency in the text usage box (for 12.34 as "123400". I would recommend to pass amount adjustments with decimal point because this would be the default string conversion in OPOS and POS for .NET implementations.
    • Since adjustmentType has only two predefined values, it should be clarified that percentage adjustments should be given with trailing percent character (e.g. 5.5% as "5.5%") and amount adjustments without percent character (e.g. 5.50 as "5.50")
  • Reported: UPOS 1.15 — Mon, 23 Jan 2023 11:09 GMT
  • Updated: Tue, 9 Jul 2024 00:52 GMT

FiscalPrinter: The format of vatAdjustment in printRecPackageAdjustmentVoid is unclear

  • Status: open  
  • Source: Free Software Developer ( Martin Conrad)
  • Summary:

    Two things are unclear:

    • Amount adjustments can be given as a decimal string (e.g. a value of 12.34 as "12.34") or as described in chapter 1.3.4 for type currency in the text usage box (for 12.34 as "123400". I would recommend to pass amount adjustments with decimal point because this would be the default string conversion in OPOS and POS for .NET implementations.
    • Since adjustmentType has only two predefined values, it should be clarified that percentage adjustments should be given with trailing percent character (e.g. 5.5% as "5.5%") and amount adjustments without percent character (e.g. 5.50 as "5.50").
  • Reported: UPOS 1.15 — Mon, 23 Jan 2023 11:50 GMT
  • Updated: Tue, 9 Jul 2024 00:52 GMT
  • Attachments:

FiscalPrinter: Unclear string format for totalizer values in getTotalizer method

  • Status: open  
  • Source: Free Software Developer ( Martin Conrad)
  • Summary:

    The format of string data returned by the getTotalizer is unclear. It should be clarified.
    Since totalizer values (e.g. grand total) may exceed limits of receipt total values, it is not clear that such values may fit into values described as type currency in the UPOS specification. In addition, there is no specification which kind of data type shall be used for totalizers.
    Expecting that OPOS uses CURRENCY, POS for .NET decimal and Java implementations perhaps BigDecimal for totalizers, getTotalizer should return values with decimal point as returned by the in-built string conversions. For example, a totalizer of 12345.67 should be returned as "12345.67".

  • Reported: UPOS 1.15 — Mon, 23 Jan 2023 10:56 GMT
  • Updated: Tue, 9 Jul 2024 00:52 GMT
  • Attachments:

FiscalPrinter: Unclear string format for totalizer values returned by getData

  • Status: open  
  • Source: Free Software Developer ( Martin Conrad)
  • Summary:

    The format of string data returned by the getData is unclear for totalizer values. It should be clarified.
    Since totalizer values (e.g. grand total) may exceed limits of receipt total values, it is not clear that such values may fit into values described as type currency in the UPOS specification. In addition, there is no specification which kind of data type shall be used for totalizers.
    Expecting that OPOS uses CURRENCY, POS for .NET decimal and Java implementations perhaps BigDecimal for totalizers, getData should return totalizer values with decimal point as returned by the in-built string conversions. For example, a totalizer of 12345.67 should be returned as "12345.67".

  • Reported: UPOS 1.15 — Mon, 23 Jan 2023 10:51 GMT
  • Updated: Tue, 9 Jul 2024 00:52 GMT
  • Attachments:

FiscalPrinter: The description of currency amounts and percentage amounts is not true for OPOS and POS for .NET environments

  • Status: open  
  • Source: Free Software Developer ( Martin Conrad)
  • Summary:

    Currency amounts and (in adjustments) percentage amounts are not passed as values with data type long in case of OPOS and POS for .NET. Instead, they are passed as values of type CURRENCY (OPOS) or decimal (POS for .NET).
    Instead, refer to chapter A.17, B.13 and C.21.1 for more details.

  • Reported: UPOS 1.15 — Mon, 23 Jan 2023 10:18 GMT
  • Updated: Tue, 9 Jul 2024 00:52 GMT
  • Attachments:

EVRW retrieveResultInformation Method did have a typo


FiscalPrinter: At Least One Constant For parameter dataItem is missing at getData

  • Status: open  
  • Source: Free Software Developer ( Martin Conrad)
  • Summary:

    For fiscal printers with capability CapHasVatTable set, a constant for dataIten with name FPTR_GD_VAT_ID_LIST should be added.
    Since there is currently no way for the application programmer to find out which VAT ids (s)he can use for a specific VAT rate, use of this constant should become the recommended way to pass the list of valid VAT ids to the application.
    My recommendation for the format of the data returned by the service is a comma separated list of double-point separated tupels, containing the VAT ID, the VAT rate (if set, else -1) and (optional) the corresponding value of the optArgs argument used in method getVatEntry, if needed.

  • Reported: UPOS 1.15 — Mon, 2 Jan 2023 23:16 GMT
  • Updated: Tue, 9 Jul 2024 00:52 GMT
  • Attachments:

EVRW State Diagrams are incorrectly copy and pasted.

  • Status: open  
  • Source: Microsoft ( Mr. Tadashi Furuhata)
  • Summary:

    UPOS 1.15 EVRW chapter had several area incorrectly copy and pasted.
    Currently we proposed UPOS 1.15 EVRW and approved AB, was the content of 15_ElectronicValueReaderWriter.pdf.
    When we compared the proposed UPOS 1.15 EVRW and current OMG pre-released UPOS 1.15 of formal-20-01-05, did have differences since it looks like having the incorrect copy and paste.
    We would like to ask correcting those as attached PNG files.
    1. EVRW State Diagrams.
    15.3.12 EVRW Sequence Diagram and following 3 sequence diagrams.
    EVRW-1.PNG
    EVRW-2.PNG
    EVRW-3 PNG
    EVRW-4.PNG
    2. 15.3.13 EVRW State Diagram
    This should be replaced as EVRW-5.PNG
    3. EVRW Service Type Property value
    EVRW_ST_CAT was missing.
    Need to change to EVRW Service Type Property Update in 1.15.PNG.
    4. 15.3.13 EVRW State Diagram
    During the copy and paste correction activity, we re-evaluate the EVRW chapter and found the need correction area.
    Since EVRW-4.PNG sequence will occur after initialization before termination.
    Therefore, we need the change this to EVRW-6.PNG
    And to make paste into the EVRW chapter, EVRW-6_State Diagram.pptx file is also attached.
    After those changes are made now, UPOS1.15.1 EVRW chapter is perfect.

  • Reported: UPOS 1.15 — Wed, 29 Jun 2022 08:51 GMT
  • Updated: Tue, 9 Jul 2024 00:52 GMT
  • Attachments:

EVRW readValue Method, transactionAccess Method, setParameterInformation Method descriptions were need to change.

  • Status: open  
  • Source: Microsoft ( Mr. Tadashi Furuhata)
  • Summary:

    1. readValue Method
    Timeout related description need to change. In addition, regarding the E_TIMEOUT Error related description need to change since it is the data writing maximum period exceeding error.
    Also, during the method execution, E_TIMEOUT will not be delivered when there is no response, ErrorEvent will be delivered instead.

    2. transactionAccess Method
    In the Remarks, description include the readValue method. The transactionAceess method is OutPut Model method and readValue method is InputModel method.
    Therefore, readValue method should be eliminated from the transactionAccess method description.

    3. setParameterInformation Method
    In this method parameter value, if parameter is not recognized or not supported, return the value does not make sence. Therefore, current description the value returned will be empty string is not correct and should be changed as nothing get changed.
    Also, in the Erros E_ILLEGAL is required, if an Invalid or unsupported parameter was specified.

    Thoese changes are needed and how to change those should be proposed.

  • Reported: UPOS 1.15 — Thu, 14 Jul 2022 13:57 GMT
  • Updated: Tue, 9 Jul 2024 00:52 GMT
  • Attachments:

SmartCardRW: UML status diagram causes confusion for readData()

  • Status: open  
  • Source: Diebold Nixdorf Global Solutions B.V. ( Mr. Denis Kuniss)
  • Summary:

    In general, this seems to be a design issue as readData() method was design to be synchronous only, but additionally it causes input data and input error events what definitely is intended only for devices which follow the asynchronous data input model. Because readData() is a synchronous method only, it normally cannot cover asynchronous input!

    As we cannot change the UPOS method syntax anymore (for removing the output parameters and moving them to properties as it would be required by the asynchronous input model) and also not the synchronous flavor, it is recommended to just correct the status diagram by removing the edges "DataEvent()" and "ErrorEvent()" and maybe add a note to readData() how this could be implemented.

    Initially reported by https://github.com/mjpcger.

    BTW, the UML diagrams are very hard to read due to a very poor density/quality!

  • Reported: UPOS 1.15 — Mon, 25 Apr 2022 13:41 GMT
  • Updated: Tue, 9 Jul 2024 00:52 GMT
  • Attachments:

SmartCardRW: endRemoval is not counted as chapter


EVRW: DailyLog has wrong mutability constraint in the Summary section


EVRW: CapDailyLog has wrong type in the Summary section


EVRW: CapAuthorizePreSales is listed 2 times in the Summary section


Add GS1-128 to Scanner to replace EAN-128

  • Key: UPOS1151-6
  • Status: open  
  • Source: Lexmark ( Mr. Andy Mattice)
  • Summary:

    GS1-128 has replaced EAN-128. Add GS1-128 as a symbology. Value= SCAN_SDT_GS1128 Label Type=GS1-128. Deprecate EAN-128 in same manner as RSS14 was deprecated and replaced with GS1-128. Update meaning to= EAN-128-Deprecated v(insert version here); replaced by SCAN_SDT_GS1128 (which has the same value

  • Reported: UPOS 1.15b2 — Sat, 19 Mar 2022 20:10 GMT
  • Updated: Tue, 9 Jul 2024 00:52 GMT
  • Attachments:

Add Dotcode to Scanner


Aztec code misspelled in Appendix C

  • Key: UPOS1151-3
  • Status: open  
  • Source: Lexmark ( Mr. Andy Mattice)
  • Summary:

    Aztec code misspelled as "Axtec" POS for .net table. Update UnifiedPOS Name to PTR_BCS_AXTEC and update Parameter name to Aztec

  • Reported: UPOS 1.15b2 — Sat, 19 Mar 2022 20:13 GMT
  • Updated: Tue, 9 Jul 2024 00:52 GMT
  • Attachments:

Add DW Code to Scanner

  • Key: UPOS1151-4
  • Status: open  
  • Source: Lexmark ( Mr. Andy Mattice)
  • Summary:

    Add Digital Watermarking to Scanner Symbology List. Value= SCAN_SDT_DWCODE Label Type_Digital Watermarking

  • Reported: UPOS 1.15b2 — Sat, 19 Mar 2022 20:12 GMT
  • Updated: Tue, 9 Jul 2024 00:52 GMT
  • Attachments:

Add GS1-128 to POS Printer to replace EAN-128

  • Key: UPOS1151-2
  • Status: open  
  • Source: Lexmark ( Mr. Andy Mattice)
  • Summary:

    GS1-`128 has replaced EAN-128. Add GS1-128 as a symbology. Value= PTR_BCS_GS1128 Meaning=GS1-128. Deprecate EAN-128 in same manner as RSS14 was deprecated and replaced with GS1-128. Highlight in red and update meaning= EAN-128-Deprecated v(insert version here); replaced by PTR_BCS_GS1128 (which has the same value)

  • Reported: UPOS 1.15b2 — Sat, 19 Mar 2022 20:09 GMT
  • Updated: Tue, 9 Jul 2024 00:52 GMT
  • Attachments:

ToneIndicator: Mismatch in access constraints between Summary and Property description sections

  • Key: UPOS1151-1
  • Status: open  
  • Source: Diebold Nixdorf Global Solutions B.V. ( Mr. Denis Kuniss)
  • Summary:

    During our ToneIndicator implementation we encountered that for several properties the access constraints in the Summary section are different from those in the sections describing the particular property. The Summary section states the properties are accessible only after enable. However, the particular property section defines the property is accessible just after open.

    The following properties are affected (all non-capabilities):

    • AsyncMode
    • InterToneWait
    • MelodyType
    • MelodyVolume
    • Tone1Duration
    • Tone1Pitch
    • Tone1Volume
    • Tone2Duration
    • Tone2Pitch
    • Tone2Volume

    We propose to resolve this differently for the particular properties:

    For AsyncMode the Summary section must be corrected to allow access just after open. This would be equal to to the constraint specified for POSPrinter or FiscalPrinter which are also output devcies.

    For all other properties the Summary section should be considered as being right and the property description section should be changed to allow the access only after enabling.

    Attached are the Summary with the constraint in question marked, and 2 examples of the property descriptions for AsyncMode and InterToneWait.

  • Reported: UPOS 1.15 — Fri, 18 Sep 2020 11:34 GMT
  • Updated: Tue, 9 Jul 2024 00:52 GMT
  • Attachments: