Unified POS Avatar
  1. OMG Specification

Unified POS — All Issues

  • Acronym: UPOS
  • Issues Count: 65
  • Description: All Issues
Open Closed All
All Issues

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
UPOS1162-2 See issue UPOS1151-11, SmartCardRW Status Diagram Confusing, readData Method Handling Unclear UPOS 1.15 open
UPOS116_-37 Electronic Journal: Bad Description for Value ER_CLEAR UPOS 1.15 open
UPOS1162-1 Bad version number used in header UPOS 1.16.1 open
UPOS1161-1 Revised UPOS 1.16 (dtc-20-12-01.docx)spec. is proposed as UPOS 1.16.1 UPOS 1.16b2 UPOS 1.16.1 Resolved closed
UPOS1161-6 Video Capture ER_CONTINUEINPUT should be ER_RETRY, "input" should be "data" UPOS 1.16b2 UPOS 1.16.1 Resolved closed
UPOS1161-4 Missing remarks, status description improvement, capability read-write vs read-only and ErrorResponse improvements UPOS 1.16b2 UPOS 1.16.1 Resolved closed
UPOS1161-3 Method and property "open claim enable" combinations and E_ILLEGAL error code definitions UPOS 1.16b2 UPOS 1.16.1 Resolved closed
UPOS1161-10 StatusUpdateEvent values and description in Remarks need improvement UPOS 1.16b2 UPOS 1.16.1 Resolved closed
UPOS1161-9 Read-only properties mistakenly marked read-write, and missing Remarks UPOS 1.16b2 UPOS 1.16.1 Resolved closed
UPOS1161-5 Cover page version and submission date UPOS 1.16b2 UPOS 1.16.1 Resolved closed
UPOS1161-8 Method behavior descriptions missing several conditions UPOS 1.16b2 UPOS 1.16.1 Resolved closed
UPOS1161-7 Method use descriptions accidentally comma delimited, not consistent with others UPOS 1.16b2 UPOS 1.16.1 Resolved closed
UPOS116_-11 Bookmarks of Summary pages are broken UPOS 1.15b2 UPOS 1.16b2 Closed; Out Of Scope closed
UPOS116_-3 Add EVRW_ST_CAT definition to ServiceType property UPOS 1.15b2 UPOS 1.16b2 Closed; Out Of Scope closed
UPOS116_-1 RCSD device description needs the more explanation about the device models and related properties methods events. UPOS 1.15 UPOS 1.16b2 Closed; No Change closed
UPOS116_-5 Table separation line layout UPOS 1.15b2 UPOS 1.16b2 Closed; Out Of Scope closed
UPOS116_-7 Version Information UPOS 1.15b2 UPOS 1.16b2 Closed; Out Of Scope closed
UPOS116_-9 Version information of PaymentDetail property UPOS 1.15b2 UPOS 1.16b2 Closed; Out Of Scope closed
UPOS116_-13 Description of the table of PaymentCondition property UPOS 1.15b2 UPOS 1.16b2 Closed; Out Of Scope closed
UPOS116_-15 Errors, See Also layout of DailyLog property UPOS 1.15b2 UPOS 1.16b2 Closed; Out Of Scope closed
UPOS116_-17 Version number for which TransisionEvent was specified UPOS 1.15b2 UPOS 1.16b2 Closed; Out Of Scope closed
UPOS116_-19 CapDailyLog type different UPOS 1.15b2 UPOS 1.16b2 Closed; Out Of Scope closed
UPOS116_-21 UPOS 1.16 RCSD all of issues are corrected and editing was completed UPOS 1.15 UPOS 1.16b2 Closed; No Change closed
UPOS116_-23 Several issues are pointed out for the UPOS1.16 FTF however they are for the UPOS1.15beta2 issues. UPOS 1.15 UPOS 1.16b2 Closed; No Change closed
UPOS-1 EVRW chapter should be updated to add the required function UPOS 1.15b1 UPOS 1.15 Resolved closed
UPOS-11 Updates needed for POSfor.NET Appendix C UPOS 1.14.2 UPOS 1.15 Resolved closed
UPOS-4 EVRW chapter should be updated to add the required function UPOS 1.15b1 UPOS 1.15 Closed; No Change closed
UPOS-3 EMV support is required for CAT and EVRW devices UPOS 1.15b1 UPOS 1.15 Duplicate or Merged closed
UPOS-8 Scale: Inconsistency in MaximumWeight and MinimumWeight description UPOS 1.15b1 UPOS 1.15 Resolved closed
UPOS-7 Enhance FiscalPrinter category for new regulation in Germany UPOS 1.15b1 UPOS 1.15 Resolved closed

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:

See issue UPOS1151-11, SmartCardRW Status Diagram Confusing, readData Method Handling Unclear

  • Key: UPOS1162-2
  • Status: open  
  • Source: Free Software Developer ( Martin Conrad)
  • Summary:

    I think the solution should not be to remove DataEvent and ErrorEvent from the status diagram. Both events are necessary to signal availability of data or reader problems to the application.
    Instead, the text in chapter 37.5 after Input should be changed as follows:

    Remove the first sentence "The application must invoke the readData method in order to request data from the smart card."

    To make it more clear, the arrows marked with "DataEvent()" and "readData(action, count, data)" should be exchanged.

  • Reported: UPOS 1.15 — Sun, 5 Mar 2023 18:00 GMT
  • Updated: Wed, 22 Mar 2023 17:00 GMT

Electronic Journal: Bad Description for Value ER_CLEAR

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

    The description for ER_CLEAR is wrong: Replace
    Clear all buffered output data including all asynchronous output. (The effect is the same as calling clearInput.)
    with
    Clear all buffered output data including all asynchronous output when locus is EL_OUTPUT and all buffered input data when locus is EL_INPUT. (The effect is the same as calling clearInput when locus is EL_INPUT or clearOutput when locus is EL_OUTPUT.)

  • Reported: UPOS 1.15 — Thu, 16 Mar 2023 23:04 GMT
  • Updated: Wed, 22 Mar 2023 15:35 GMT

Bad version number used in header

  • Key: UPOS1162-1
  • Status: open  
  • Source: Private ( Martin Conrad)
  • Summary:

    UPOS version 1.16.1 seems to add and extend UPOS 1.15, not 1.16. UPOS 1.16 does not exist.
    However, should I be wrong and UPOS version 1.16 does exist, the specification is not on your web site (History consists of specifications UPOS 1.15 and UPOS 1.16.1 only).
    In addition, in both 1.16.1 specifications (normative and informative document), no bookmarks are present, making it hard to work with both of them.

  • Reported: UPOS 1.16.1 — Sun, 16 Oct 2022 22:15 GMT
  • Updated: Wed, 26 Oct 2022 15:54 GMT

Revised UPOS 1.16 (dtc-20-12-01.docx)spec. is proposed as UPOS 1.16.1

  • Key: UPOS1161-1
  • Status: closed  
  • Source: Microsoft ( Mr. Tadashi Furuhata)
  • Summary:

    We have found an item in UPOS 1.16 (dtc-20-12-01.docx) that needs to be modified as a specification.
    All of these items are extracted, issues and correction items are clearly shown, and the corrections and edits of the specification items are proposed as UPOS 1.16.1.
    Attached documents are as follows.
    1) UPOS RCSD 1.16 Issues Table
    Note :All of the to be corrected items in the UPOS 1.16 spec. is listed up.
    2) UPOS RCSD 1.16.1_withBar.docx
    Note: All of the issues to be corrected is listed and indicated line by line with the explanation.
    3) UPOS RCSD 1.16.1_clean.docx
    Note: Clean file of UPOS RCSD 1.16.1
    These documents have only RCSD related 11 device chapters.
    That is to say;
    Chapter 21 Lights
    Chapter 29 POS Power
    Chapter 39 Video Capture
    Chapter 40 Individual Recognition
    Chapter 41 Sound Recorder
    Chapter 42 Voice Recognition
    Chapter 43 Sound Player
    Chapter 44 Speech Synthesis
    Chapter 45 Gesture Control
    Chapter 46 Device Monitor
    Chapter 47 Graphic Display

  • Reported: UPOS 1.16b2 — Thu, 18 Nov 2021 14:04 GMT
  • Disposition: Resolved — UPOS 1.16.1
  • Disposition Summary:

    All of UPOS1.16.1 issue resolved documents

    After discussion with Denis and OMG Retail DTF member, finally we reached to the all issues resolved version.
    As the final submission version documents are listed below.
    1. Original UPOS 1.16
    dtc-20-12-01.docx
    2. UPOS1.16 Issue and Resolved Item Listed Table
    UPOS RCSD 1.16 Issues Table_02032022.xlsx
    3. UPOS1.16.1 with Bar + Issue Item and revised item Table
    UPOS RCSD 1.16.1_02032022_withBar.docx
    4. UPOS1.16.1 clean Version (UPOS1.16.1 Final Version Candidate)
    UPOS RCSD 1.16.1_02032022_clean.docx

    Please take look at those, and after your review, I would like to go to the voting for your approval.

    Regards.

    Tad Furuhata

  • Updated: Wed, 13 Jul 2022 14:18 GMT
  • Attachments:

Video Capture ER_CONTINUEINPUT should be ER_RETRY, "input" should be "data"

  • Key: UPOS1161-6
  • Status: closed  
  • Source: Lexmark ( Mr. Andy Mattice)
  • Summary:

    Video Capture ER_CONTINUEINPUT should be ER_RETRY, "input" should be "data"

    Examples:

    Error Event behavior was incorrect.

    ER_CONTINUEINPUT was incorrect and should be changed to
    ER_RETRY

    clearInput method description of "input" should be changed to "data".

    ErrorEvent description of "input" should be changed to "data".

    -------------

    Issue Group D

    Remarks in bar doc:

    P89
    P90
    P91

  • Reported: UPOS 1.16b2 — Wed, 23 Mar 2022 03:36 GMT
  • Disposition: Resolved — UPOS 1.16.1
  • Disposition Summary:

    Video Capture ER_CONTINUEINPUT to ER_RETRY, and "input" to "data"

    See attached spreadsheet for extent of modifications.

    Video Capture ER_CONTINUEINPUT should be ER_RETRY, "input" should be "data"

  • Updated: Wed, 13 Jul 2022 14:18 GMT
  • Attachments:

Missing remarks, status description improvement, capability read-write vs read-only and ErrorResponse improvements

  • Key: UPOS1161-4
  • Status: closed  
  • Source: Lexmark ( Mr. Andy Mattice)
  • Summary:

    Missing remarks, repairing typos and descriptions. Retry behavior improperly documented for input vs output device behavior.

    Examples:

    Capability needs to be used under the read-only, however description was read-write. This should be corrected.

    In addition, regarding the Remarks section, description was not good enough to explain this property’s behavior.

    In the Remarks initialization description was missing.

    In the See also section, referenced properties were missing.

    In Attribute, regarding the ErrorResponse value, ER_RETRY should be eliminated, since this is the input device.
    Also, in the ER_CLEAR output device related description was corrected since there are typo of loci and there is not output data because of input device.

    In See Also section, Status, Error code, State model description were not needed.
    Then “Device Input Model” on page Intro-22” and “Error Handling” on page Intro-23 were added instead.

    -------------

    Issue Group B

    Remarks in bar doc:

    P84
    P85
    P89
    P90
    P90
    P90
    P91
    P93
    P96
    P97
    P102
    P106
    P107
    P108
    P113
    P128
    P129
    P138
    P143
    P146
    P164
    P174
    P174
    P178
    P196
    P205
    P218
    P232
    P240
    P241
    P241
    P246
    P247
    P252
    P252
    P254

  • Reported: UPOS 1.16b2 — Wed, 23 Mar 2022 03:16 GMT
  • Disposition: Resolved — UPOS 1.16.1
  • Disposition Summary:

    Added missing remarks, improved status descriptions, repaired capability read-write vs read-only and ErrorResponse improvements for UPOS1161-4

    See attached spreadsheet for extent of modifications.

    Example:

    39/ Video Capture

    CapAssociatedHardTotalsDevice Property

    Capability needs to be used under the read-only, however description was read-write. Therefore, it was changed from read-write to read-writeonly.
    In addition, regarding the Remarks section, description was not good enough to explain this property’s behavior.
    Therefore, “Holds the open name of the associated Hard Totals device, if the device is able to write to such devices which is the case, if CapStorage is either VCAP_CST_ALL or VCAP_CST_HARDTOTALS_ONLY.
    If CapStorage is VCAP_CST_HOST_ONLY this property value must be the empty string. “was corrected as follows.
    “Indicate that the device is able to store the recorded data into the Associated Hard Totals device and Hholds the its open name of the associated Hard Totals Device, if the device is able to write to such devices which is the case, if CapStorage is either VCAP_CST_ALL or VCAP_CST_HARDTOTALS_ONLY.
    If CapStorage is VCAP_CST_HOST_ONLY, the device is not able to store the data into the Associated Hard Totals device and this property value must be the empty string. This property is initialized by the open method.

  • Updated: Wed, 13 Jul 2022 14:18 GMT
  • Attachments:

Method and property "open claim enable" combinations and E_ILLEGAL error code definitions

  • Key: UPOS1161-3
  • Status: closed  
  • Source: Lexmark ( Mr. Andy Mattice)
  • Summary:

    Repairing documentation to match expected implementation.

    Examples:

    This method can be used after open claim enable, however summary section missing the claim and it was added in the use after section.

    This property is able to read and write. In that case there should be the E_ILLEGAL error code. However, that description was missing. Therefore, E_ILLEGAL related description was added as listed below.
    Some possible values of the exception’s ErrorCode property are:
    Value Meaning
    E_ILLEGAL An invalid value was specified.

    --------------

    Issue Group A

    Remarks in bar doc:

    P38
    P52
    P67
    P68
    P74
    P85
    P92
    P93
    P99
    P100
    P101
    P102
    P103
    P104
    P105
    P106
    P107
    P116
    P126
    P133
    P139
    P140
    P141
    P149
    P168
    P175
    P181
    P199
    P221
    P235
    P236
    P247

  • Reported: UPOS 1.16b2 — Wed, 23 Mar 2022 03:01 GMT
  • Disposition: Resolved — UPOS 1.16.1
  • Disposition Summary:

    Property and method descriptions adjusted for UPOS1161-3

    See attached spreadsheet for proposed modifications.

    Example:

    39/ Video Capture

    VideoFrameRate Property

    This property needs to be used under the open, claim enable, however is the spec claim, enable were missing and newly added.
    Access after open, claim enable.
    In the See also section, CapVideoFrameRate Property was missing, therefore it was added.

  • Updated: Wed, 13 Jul 2022 14:18 GMT
  • Attachments:

StatusUpdateEvent values and description in Remarks need improvement

  • Status: closed  
  • Source: Lexmark ( Mr. Andy Mattice)
  • Summary:

    StatusUpdateEvent values and description in Remarks need improvement

    Examples:

    39/ Video Capture

    TakePhoto

    In the Remarks, StatusUpdateEvent related description was not good enough. Therefore, those description was added.
    “The process of recorded data storing is performed asynchronously. StatusUpdateEvents are invoked for delivered to the application when the start and the end state were changed.”

    -------------

    Issue Group H

    Remarks in bar doc:

    P89
    P90
    P109
    P110
    P111
    P114

  • Reported: UPOS 1.16b2 — Wed, 23 Mar 2022 04:06 GMT
  • Disposition: Resolved — UPOS 1.16.1
  • Disposition Summary:

    Improved StatusUpdateEvent values and description in Remarks

    Method descriptions, remarks and specific instances of StatusUpdateEvent needed improvement.

  • Updated: Wed, 13 Jul 2022 14:18 GMT
  • Attachments:

Read-only properties mistakenly marked read-write, and missing Remarks

  • Key: UPOS1161-9
  • Status: closed  
  • Source: Lexmark ( Mr. Andy Mattice)
  • Summary:

    Read-only properties mistakenly marked read-write, and missing Remarks

    Examples:

    43/ Sound Player

    CapAssociatedHardTotalsDevice Property

    This property can be used as read only, therefore, read-write was corrected as read-only.
    In the Remarks initialization description was missing.
    Therefore, this description was added.
    This property is initialized by the open method.

    -------------

    Issue Group G

    Remarks in bar doc:

    P168
    P173
    P188
    P243

  • Reported: UPOS 1.16b2 — Wed, 23 Mar 2022 04:01 GMT
  • Disposition: Resolved — UPOS 1.16.1
  • Disposition Summary:

    Fixed read-only property designations and added missing remarks for UPOS1161-9

    Some properties were mistakenly described as read-write when they should be read-only. Also clarified descriptions.

  • Updated: Wed, 13 Jul 2022 14:18 GMT
  • Attachments:

Cover page version and submission date

  • Key: UPOS1161-5
  • Status: closed  
  • Source: Lexmark ( Mr. Andy Mattice)
  • Summary:

    Cover page version and submission date

    Examples:

    In the cover page there was an old description. This specification proposing the UPOS 1.16.1 and it editing the UPOS1.16. Also, documentation submission date is Sept. 2021.

    -------------

    Issue Group C

    Remarks in bar doc:

    P14

  • Reported: UPOS 1.16b2 — Wed, 23 Mar 2022 03:28 GMT
  • Disposition: Resolved — UPOS 1.16.1
  • Disposition Summary:

    Cover page and submission date adjusted for UPOS1161-5

    In the cover page there was an old description. This specification was intended to be UPOS 1.16.1 as an adjustment to UPOS1.16. Also, documentation submission date was Sept. 2021.

  • Updated: Wed, 13 Jul 2022 14:18 GMT

Method behavior descriptions missing several conditions

  • Key: UPOS1161-8
  • Status: closed  
  • Source: Lexmark ( Mr. Andy Mattice)
  • Summary:

    Method behavior descriptions missing several conditions

    Examples:

    47/ Graphic Display...

    clearInput Method, clearInputProperties Method, clearOutput Method

    This method behavior description missing the several conditions. Therefore, those are newly added.

    void:

    {raises-exception, use after open, claim}

    -------------

    Issue Group F

    Remarks in bar doc:

    P116
    P132
    P133
    P149
    P168
    P181
    P182
    P199
    P221
    P235
    P236

  • Reported: UPOS 1.16b2 — Wed, 23 Mar 2022 03:48 GMT
  • Disposition: Resolved — UPOS 1.16.1
  • Disposition Summary:

    Added missing method conditions for UPOS1161-8

    See attached spreadsheet for extent of modifications.

    Example:

    42/ Voice Recognition
    ClearInput Method,
    ClearInputProperties Method

    Added: void:

    {raises-exception, use after open, claim}
  • Updated: Wed, 13 Jul 2022 14:18 GMT
  • Attachments:

Method use descriptions accidentally comma delimited, not consistent with others

  • Key: UPOS1161-7
  • Status: closed  
  • Source: Lexmark ( Mr. Andy Mattice)
  • Summary:

    Method use descriptions accidentally comma delimited, not consistent with others

    Examples:

    POS Power restartPOS and shutdownPOS methods...

    Therefore, use after open,
    enable is changed to use after open-enable.

    -------------

    Issue Group E

    Remarks in bar doc:

    P77
    P78
    P90
    P91
    P194

  • Reported: UPOS 1.16b2 — Wed, 23 Mar 2022 03:42 GMT
  • Disposition: Resolved — UPOS 1.16.1
  • Disposition Summary:

    Repaired "method use" descriptions for UPOS1161-7

    See attached spreadsheet for extent of modifications.

    Some "method use" descriptions needed clarification and repair of dashed-terminology that was comma-delimited.

  • Updated: Wed, 13 Jul 2022 14:18 GMT
  • Attachments:

Bookmarks of Summary pages are broken

  • Status: closed  
  • Source: Individual ( Kunio Fukuchi)
  • Summary:

    The bookmarks on the summary pages of many devices are broken, and there are many meaningless bookmarks.

  • Reported: UPOS 1.15b2 — Sat, 3 Aug 2019 06:07 GMT
  • Disposition: Closed; Out Of Scope — UPOS 1.16b2
  • Disposition Summary:

    This is not a UPOS 1.16 RCSD Issue and should be transferred to UPOS 1.15 FTF

    This is not included in the UPOS 1.16 RCSD specification.
    Therefore, as UPOS 1.16 RCSD specification does not include this.
    And this should be closes as out of scope.

  • Updated: Thu, 1 Apr 2021 20:58 GMT

Add EVRW_ST_CAT definition to ServiceType property

  • Key: UPOS116_-3
  • Status: closed  
  • Source: Individual ( Kunio Fukuchi)
  • Summary:

    Improvement advice
    A value that classifies the service function added in version 1.16 has not been added.

  • Reported: UPOS 1.15b2 — Thu, 8 Aug 2019 09:58 GMT
  • Disposition: Closed; Out Of Scope — UPOS 1.16b2
  • Disposition Summary:

    This is not a UPOS 1.16 RCSD Issue and should be transferred to UPOS 1.15 FTF

    EVRW is not described in UPOS 1.16 RCSD specification, therefore this issue and correction should be done in UPOS 1.15 whole specification.
    Therefore as UPOS 1.16 RCSD this should be closes as out of scope.

  • Updated: Thu, 1 Apr 2021 20:58 GMT

RCSD device description needs the more explanation about the device models and related properties methods events.


Table separation line layout

  • Key: UPOS116_-5
  • Status: closed  
  • Source: Individual ( Kunio Fukuchi)
  • Summary:

    In each of the following, the start position of the line that separates the item names in the table and the explanation of the values is at the left end of the page.

    14-15 CapDailyLog Property
    14-60 PaymentCondition Property
    14-68 PaymentMedia Property
    14-73 TransactionType Property
    14-76, 14-77 accessDailyLog Method
    14-83 -> 14-88 authorizeCompletion Method to authorizeVoidPreSales Method
    14-92 cashDeposit Method
    14-93 checkCard Method

  • Reported: UPOS 1.15b2 — Thu, 1 Aug 2019 12:17 GMT
  • Disposition: Closed; Out Of Scope — UPOS 1.16b2
  • Disposition Summary:

    This is not a UPOS 1.16 RCSD Issue and should be transferred to UPOS 1.15 FTF

    This is not included in the UPOS 1.16 RCSD specification.
    Therefore, as UPOS 1.16 RCSD specification does not include this.
    And this should be closes as out of scope.

  • Updated: Thu, 1 Apr 2021 20:58 GMT

Version Information

  • Key: UPOS116_-7
  • Status: closed  
  • Source: Individual ( Kunio Fukuchi)
  • Summary:

    Although updated information is not described, Update in Release 1.15 is added below.
    15-10 General Information
    15-48 CountryCode Property
    because added Germany

    15-50 DateType Property
    because added TICKET_START, TICKET_END

  • Reported: UPOS 1.15b2 — Thu, 1 Aug 2019 12:02 GMT
  • Disposition: Closed; Out Of Scope — UPOS 1.16b2
  • Disposition Summary:

    This is not a UPOS 1.16 RCSD Issue and should be transferred to UPOS 1.15 FTF

    This is not included in the UPOS 1.16 RCSD specification.
    Therefore, as UPOS 1.16 RCSD specification does not include this.
    And this should be closes as out of scope.

  • Updated: Thu, 1 Apr 2021 20:58 GMT

Version information of PaymentDetail property

  • Key: UPOS116_-9
  • Status: closed  
  • Source: Individual ( Kunio Fukuchi)
  • Summary:

    It is described as Added in Release 1.9, but it is correctly Added in Release 1.15.

  • Reported: UPOS 1.15b2 — Thu, 1 Aug 2019 11:54 GMT
  • Disposition: Closed; Out Of Scope — UPOS 1.16b2
  • Disposition Summary:

    This is not a UPOS 1.16 RCSD Issue and should be transferred to UPOS 1.15 FTF

    This is not included in the UPOS 1.16 RCSD specification.
    Therefore, as UPOS 1.16 RCSD specification does not include this.
    And this should be closes as out of scope.

  • Updated: Thu, 1 Apr 2021 20:58 GMT

Description of the table of PaymentCondition property

  • Status: closed  
  • Source: Individual ( Kunio Fukuchi)
  • Summary:

    Descriptions of Value and Meaning of BONUS_COMBINATION_X are not separated and appear to be connected.

  • Reported: UPOS 1.15b2 — Thu, 1 Aug 2019 11:51 GMT
  • Disposition: Closed; Out Of Scope — UPOS 1.16b2
  • Disposition Summary:

    This is not a UPOS 1.16 RCSD Issue and should be transferred to UPOS 1.15 FTF

    This is not included in the UPOS 1.16 RCSD specification.
    Therefore, as UPOS 1.16 RCSD specification does not include this.
    And this should be closes as out of scope.

  • Updated: Thu, 1 Apr 2021 20:58 GMT

Errors, See Also layout of DailyLog property

  • Status: closed  
  • Source: Individual ( Kunio Fukuchi)
  • Summary:

    The indent position / bold of the item name has been moved to the text part.

  • Reported: UPOS 1.15b2 — Thu, 1 Aug 2019 11:43 GMT
  • Disposition: Closed; Out Of Scope — UPOS 1.16b2
  • Disposition Summary:

    This is not a UPOS 1.16 RCSD Issue and should be transferred to UPOS 1.15 FTF

    This is not included in the UPOS 1.16 RCSD specification.
    Therefore, as UPOS 1.16 RCSD specification does not include this.
    And this should be closes as out of scope.

  • Updated: Thu, 1 Apr 2021 20:58 GMT

Version number for which TransisionEvent was specified

  • Status: closed  
  • Source: Individual ( Kunio Fukuchi)
  • Summary:

    It is described as 1.15, but it is correctly 1.14.

  • Reported: UPOS 1.15b2 — Thu, 1 Aug 2019 11:36 GMT
  • Disposition: Closed; Out Of Scope — UPOS 1.16b2
  • Disposition Summary:

    This is not a UPOS 1.16 RCSD Issue and should be transferred to UPOS 1.15 FTF

    This is not included in the UPOS 1.16 RCSD specification.
    Therefore, as UPOS 1.16 RCSD specification does not include this.
    And this should be closes as out of scope.

  • Updated: Thu, 1 Apr 2021 20:58 GMT

CapDailyLog type different

  • Status: closed  
  • Source: Individual ( Kunio Fukuchi)
  • Summary:

    It is described as boolean, but it is correctly int32.

  • Reported: UPOS 1.15b2 — Thu, 1 Aug 2019 11:31 GMT
  • Disposition: Closed; Out Of Scope — UPOS 1.16b2
  • Disposition Summary:

    This is not a UPOS 1.16 RCSD Issue and should be transferred to UPOS 1.15 FTF

    This is not included in the UPOS 1.16 RCSD specification.
    Therefore, as UPOS 1.16 RCSD specification does not include this.
    And this should be closes as out of scope.

  • Updated: Thu, 1 Apr 2021 20:58 GMT

UPOS 1.16 RCSD all of issues are corrected and editing was completed

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

    UPOS 1.16 RCSD Final Candidate specification documents are availablle now as listed in this document.
    We got many points to be corrected from the Retail DTF members during the UPOS 1.16 FTF process and discussion.
    Now, all of issues and solutions are listed in the attached spread sheet.
    Finally, all of UPOS 1.16 RCSD specifition editing and corrections are completed.
    Please refer to the attached files and would like to ask voting to close this FTF.

    Here is the document names and purpose of each document.
    1. UPOS 1.16 Issues and Solution Table_05152020.xlsx
    => List of all issues and its solutions
    2. retail-19-07-04_Original.docx
    => UPOS1.16 RCSD specification original document as 1.16 beta2
    3. retail-19-07-04_Revised_05152020_Clean.docx
    => UPOS 1,16 RCSD completed specification clean version
    4. retail-19-07-04-Revised_05152020_withBar.docx
    => UPOS 1.16 RCSD completed specificaion with bar version
    5. UPOS 1.16 RCSD XML Files 05142020.zip
    => UPOS 1.16 RCSD Class diagram xmi files

    // end

  • Reported: UPOS 1.15 — Fri, 15 May 2020 04:18 GMT
  • Disposition: Closed; No Change — UPOS 1.16b2
  • Disposition Summary:

    *All of required correction and editing was completed. *

    All of issues are resolved by the proposal for UPOS116-1.
    Therefore this issue is also resolved.

  • Updated: Thu, 1 Apr 2021 20:58 GMT
  • Attachments:

Several issues are pointed out for the UPOS1.16 FTF however they are for the UPOS1.15beta2 issues.

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

    Some issues are corrected from dtc-18-12-20 to smsc-20-02.01.
    However still several issues are remaining.

    1) 15.2 Summary CapDailyLogType was incorrect
    2) 15.6.6 TransitionEvent TransitionEvent Updated timing is incorrect
    3) 14.4.48 DailyLog Property In this section See also description format is incorrect.
    4) 14.4.55 PaymentCondition Property This section's description format is incorrect.
    5) 15.4.56 PaymentDetail Property This property's updated timing is incorrect.
    6) 16.3 General Information German Fiscal Information was missing.
    7) Each section's Format is not good shape
    Added or Updated line description should be in 1 line not 2 lines.
    Need to add the ruled line in the parameter, value and meaning section.

  • Reported: UPOS 1.15 — Tue, 3 Mar 2020 06:35 GMT
  • Disposition: Closed; No Change — UPOS 1.16b2
  • Disposition Summary:

    *All of required correction and editing was completed. *

    All of issues are resolved by the proposal of UPOS116-1.
    Therefore, this issue is also resolved.

  • Updated: Thu, 1 Apr 2021 20:58 GMT
  • Attachments:

EVRW chapter should be updated to add the required function

  • Key: UPOS-1
  • Status: closed  
  • Source: Microsoft ( Mr. Tadashi Furuhata)
  • Summary:

    EMV card function to support non-contact and contact IC cards are required in the EVRW card device.
    All in one card that both credit card authorization function and EVRW function are existing, but to make both functions are not existing. Now market need the device to make the payment process both credit card authorization and EVRW are required.

  • Reported: UPOS 1.15b1 — Tue, 29 May 2018 21:55 GMT
  • Disposition: Resolved — UPOS 1.15
  • Disposition Summary:

    Add the EMV function into the EVRW spec. and extend the EVRW spec to fit with the all in one IC card that has both Credit card and EVRW function.

    To support the EMV function is mandate to the payment terminal to be used in the market. Therefore, it is required to add the EMV function into the EVRW payment device to support both contact IC card and non-contact IC card to be used as EMV cards.
    Currently, credit authorization card and Electric Value Reader / Writer card was different, however, all in one card that support both credit card function and EVRW function are in the market and to support both credit authorization card and EVRW card supporting device are requested.
    To support both credit authorization card and EVRW card, to make the extended spec. it is better to extend the EVRW card reader device. Since EVRW function is much bigger and does have this several credit card authorization card function already.

  • Updated: Mon, 1 Apr 2019 18:20 GMT
  • Attachments:

Updates needed for POSfor.NET Appendix C

  • Key: UPOS-11
  • Status: closed  
  • Source: Microsoft ( Mr. Tadashi Furuhata)
  • Summary:

    There are several items that need to be updated in the POSfor.NET Appendix C.
    Specifically, the Device Category Support Level Table contains important reference information for many POSfor.NET users.

  • Reported: UPOS 1.14.2 — Mon, 15 Oct 2018 02:13 GMT
  • Disposition: Resolved — UPOS 1.15
  • Disposition Summary:

    UPOS1.15 POSfor.NET Appendix C chapter updated document Submission.

    According to the issues information that UPOS 1.15 POSfor.NET Appendix C needs to be updated, I checked all of the required update items.
    I discussed with Mr. Terry Warwick of Microsoft to verify the updates needed for Appendix C. Since, items to be updated came from .NET technology and UPOS changes. In cooperation with Microsoft and OPOS-J, the needed revisions were identified and documented in the attachment.
    Please refer to the revised UPOS 1.15 POSfor.NET Appendix C.

  • Updated: Mon, 1 Apr 2019 18:20 GMT
  • Attachments:

EVRW chapter should be updated to add the required function

  • Key: UPOS-4
  • Status: closed  
  • Source: Microsoft ( Mr. Tadashi Furuhata)
  • Summary:

    EMV Card function to suport the contact and non contact IC card is not included in the EVRW device. In the market now Credit Card Authorization terminal and EVRW devices are different.
    However in the market there is the card that have both credit authorization function and EVRW function are existing. And now to take care of those function in one devices are required.

  • Reported: UPOS 1.15b1 — Tue, 29 May 2018 21:36 GMT
  • Disposition: Closed; No Change — UPOS 1.15
  • Disposition Summary:

    *This is already proosed in UPOS-2 solution prposal. *

    Please refer to the UPOS-2 proposal comments.
    Just in case, proposed detailed EVRW spec. is attached.

  • Updated: Mon, 1 Apr 2019 18:20 GMT
  • Attachments:

EMV support is required for CAT and EVRW devices

  • Key: UPOS-3
  • Status: closed   Implementation work Blocked
  • Source: Aptos ( Mr. Leonid Rubakhin)
  • Summary:

    UPOS 1.14.1 specification for Credit Authorization Terminal (CAT) and Electronic Value Reader/Writer (EVRW) does not support the EMV card processing. EMV cards store data on Integrated Circuit (IC). To improve the security of CAT and EVRW, support for EMV payment method is necessary. The EMV support should cover both contact (inserted into a reader) and contactless (read over short distance) cards.

  • Reported: UPOS 1.15b1 — Thu, 24 May 2018 12:59 GMT
  • Disposition: Duplicate or Merged — UPOS 1.15
  • Disposition Summary:

    UPOS-3 is is duplicate of UPOS-1

    Issue UPOS-3 should be closed as duplicate of UPOS-1.

  • Updated: Mon, 1 Apr 2019 18:20 GMT

Scale: Inconsistency in MaximumWeight and MinimumWeight description

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

    Both property descriptions, MaximumWeight and MinimumWeight, contain the following sentence.

    Changing the WeightUnit property will also cause this property to change.

    This sentence is wrong as the property WeightUnit is defined as read-only.

  • Reported: UPOS 1.15b1 — Mon, 27 Aug 2018 11:01 GMT
  • Disposition: Resolved — UPOS 1.15
  • Disposition Summary:

    Replace by a consistent sentence

    Diebold Nixdorf proposes to replace the wrong sentence

    Changing the WeightUnit property will also cause this property to change.

    in properties MaximumWeight and MinimumWeight by the sentence

    The value held by this property must be processed considering the value returned by the WeightUnit property.

    The reason for this is that we have encountered the need to change the WeigthUnit property value from inside the service implementation even after the device has been enabled (what is not forbidden explicitly and therefore considered it as allowed). So, the value may not be fixed during the life time of the service instance. Therefore it is important for an application to process both properties, MaximumWeight/WeightUnit and MinimumWeight/WeightUnit, always together to get correct results.

  • Updated: Mon, 1 Apr 2019 18:20 GMT

Enhance FiscalPrinter category for new regulation in Germany

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

    From 2020 a new fiscal regulation will be in place in Germany. For that a certified technical safety device has been defined which has to be installed to log retail business transaction data.

    Even if this device is not a printer as nothing is printed, only data is stored, the workflow for logging the fiscal data is similar to FiscalPrinter devices in other fiscal countries. Until the UnifiedPOS 2 Fiscal API is not ready, it seems pragmatically sufficient to reuse the FiscalPrinter API from UnifiedPOS 1 to satisfy the German new regulation.

    A major requirement from the regulation is to print a regulation conform receipt. Whereas the format of the receipt is completely free (therefore the maybe already implemented POSPrinter API can be reused here by the applications), the content is regulated.
    One of the content requirements is to print the date and time of start and end of the business transaction.

    This requires the application to fetch those date and time information from the device. There is a method getDate with property DateType to fetch date and time information from a FiscalPrinter device. Unfortunately, there is no adequate enumeration values defined for fetching the date-time of a receipt start or end.

  • Reported: UPOS 1.15b1 — Mon, 27 Aug 2018 09:46 GMT
  • Disposition: Resolved — UPOS 1.15
  • Disposition Summary:

    Add new enumaration values to the FiscalPrinter category

    Diebold Nixdorf proposes to add the following enumeration values to the definition of the property DateType:

    FPTR_DT_TICKET_START: The date and time when the current fiscal receipt was started. If no fiscal receipt is opened currently, the date and time when the last receipt was opened.

    FPTR_DT_TICKET_END: The date and time when the last fiscal receipt was closed.

    Additionally, for consistency, we propose to add Germany to the list of fiscal countries the property CountryCode may hold:

    FPTR_CC_Germany: The Fiscal Printer device supports German fiscal rules, but may not print fiscal receipts, only business transaction data is registered.

  • Updated: Mon, 1 Apr 2019 18:20 GMT