${taskforce.name} Avatar
  1. OMG Task Force

UnifiedPOS 1.15.1 RTF — All Issues

Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
UPOS1151-18 FiscalPrinter: At Least One Constant For parameter dataItem is missing at getData UPOS 1.15 open
UPOS1151-1 ToneIndicator: Mismatch in access constraints between Summary and Property description sections UPOS 1.15 open
UPOS1151-11 SmartCardRW: UML status diagram causes confusion for readData() UPOS 1.15 open
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-36 Point Card Reader / Writer: Wrong Section Numbers Starting at 28.4.3 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-34 Nonsensical Chapter Hierarchy UPOS 1.15 open
UPOS1151-23 FiscalPrinter: The format of vatAdjustment in printRecPackageAdjustmentVoid is unclear UPOS 1.15 open
UPOS1151-22 FiscalPrinter: The format of vatAdjustment in printRecPackageAdjustment is unclear 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-32 Pin Pad: Property MinimumPINLength is read-write UPOS 1.15 open
UPOS1151-31 Several Errors in Point Card Reader State Diagram UPOS 1.15 open
UPOS1151-30 EVRW: _Currency_ type format makes no sense for OPOS and POS for .NET UPOS 1.15 open
UPOS1151-21 FiscalPrinter: Unclear string format for totalizer values in getTotalizer method UPOS 1.15 open
UPOS1151-24 Electronic Journal: Value format of property MediumFreeSpace should be clarified. 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-28 EVRW: Format of DailyLog unclear UPOS 1.15 open
UPOS1151-29 EVRW: Format of PaymentDetail unclear UPOS 1.15 open
UPOS1151-25 Electronic Journal: Value format of property MediumSize should be clarified. UPOS 1.15 open
UPOS1151-17 EVRW retrieveResultInformation Method did have a typo UPOS 1.15 open
UPOS1151-14 EVRW readValue Method, transactionAccess Method, setParameterInformation Method descriptions were need to change. UPOS 1.15 open
UPOS1151-13 EVRW State Diagrams are incorrectly copy and pasted. 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-4 Add DW Code to Scanner UPOS 1.15b2 open
UPOS1151-3 Aztec code misspelled in Appendix C UPOS 1.15b2 open
UPOS1151-2 Add GS1-128 to POS Printer to replace EAN-128 UPOS 1.15b2 open

Issues Descriptions

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: Thu, 29 Feb 2024 14:34 GMT

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: Thu, 11 Jan 2024 14:47 GMT

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: Mon, 11 Dec 2023 11:50 GMT
  • Attachments:

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: Thu, 15 Jun 2023 12:50 GMT

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: Thu, 15 Jun 2023 12:50 GMT

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

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

    The type for property CapCardEntranceSensor must be changed from int32 to bool. See chapter 28.4.2.

  • Reported: UPOS 1.15 — Sat, 22 Apr 2023 19:44 GMT
  • Updated: Tue, 25 Apr 2023 08:17 GMT

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

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

    Since there is one section for each property, property CapCharacterSet should not be described within chapter 28.4.2 CapCardEntranceSensor Property. Instead, 28.4.3 CapCharacterSet Property should be inserted behind the Errors section of the description for property CapCardEntranceSensor.
    In addition, chapters 28.4.3 - 28.4.51 should be changed to chapter 28.4.4 - 28-4-52.

  • Reported: UPOS 1.15 — Sat, 22 Apr 2023 19:09 GMT
  • Updated: Mon, 24 Apr 2023 16:14 GMT

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: Mon, 24 Apr 2023 16:13 GMT

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: Mon, 24 Apr 2023 16:12 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: Wed, 12 Apr 2023 22:01 GMT

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: Wed, 12 Apr 2023 21:59 GMT

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: Wed, 12 Apr 2023 19:28 GMT

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: Wed, 12 Apr 2023 19:03 GMT

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: Fri, 31 Mar 2023 18:27 GMT

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: Fri, 31 Mar 2023 18:24 GMT

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, 24 Jan 2023 16:28 GMT

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, 24 Jan 2023 16:17 GMT

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, 24 Jan 2023 16:16 GMT

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, 24 Jan 2023 15:12 GMT

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, 24 Jan 2023 15:11 GMT

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, 24 Jan 2023 15:10 GMT

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, 24 Jan 2023 15:09 GMT

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, 24 Jan 2023 14:52 GMT

EVRW retrieveResultInformation Method did have a typo

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

    According our strict review regarding the EVRW, we found the type in the retireveResultInformation Method description.

    In there, there is a table of the Enumerated tags.
    At the transaction type tag, there is a pre-sales related.
    It wasy, "EVRW_TAG_TT_Pre-SALES", however, this should be "EVRW_TAG_TT_PRE_SALES"
    Since "-" is not a good one to use the UPOS App. and this should be "_"
    This correction included document is attached.

  • Reported: UPOS 1.15 — Wed, 31 Aug 2022 06:33 GMT
  • Updated: Wed, 31 Aug 2022 06:33 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: Thu, 14 Jul 2022 15:40 GMT

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: Wed, 29 Jun 2022 08:51 GMT
  • Attachments:


EVRW: DailyLog has wrong mutability constraint in the Summary section

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

    Must be read-only according to the detailed description in the Properties section, but is read-write in the Summary section.

  • Reported: UPOS 1.15 — Thu, 21 Apr 2022 14:51 GMT
  • Updated: Wed, 27 Apr 2022 08:49 GMT

EVRW: CapDailyLog has wrong type in the Summary section

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

    Must be int, not boolean

  • Reported: UPOS 1.15 — Thu, 21 Apr 2022 14:43 GMT
  • Updated: Wed, 27 Apr 2022 08:48 GMT

EVRW: CapAuthorizePreSales is listed 2 times in the Summary section

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

    Probably the second is meant as CapAuthorizeVoidPreSales. Because this capability is missed at all in the Summary section but described in the Method section.

  • Reported: UPOS 1.15 — Thu, 21 Apr 2022 14:40 GMT
  • Updated: Wed, 27 Apr 2022 08:45 GMT
  • Attachments:

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: Wed, 27 Apr 2022 08:36 GMT

Add Dotcode to Scanner

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

    Add Dotcode to Scanner Symbology List under 2D symbologies. Value= SCAN_SDT_DOTCODE Label Type_Dotcode

  • Reported: UPOS 1.15b2 — Sat, 19 Mar 2022 20:11 GMT
  • Updated: Wed, 27 Apr 2022 08:28 GMT

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: Wed, 27 Apr 2022 08:26 GMT

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: Wed, 27 Apr 2022 08:23 GMT

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: Wed, 27 Apr 2022 08:22 GMT