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.

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").

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

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.

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.

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.

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.

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.

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.

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).

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).

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.

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).

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.

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.

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")

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").

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".

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".

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.

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.

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.

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.

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.

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!

Subsequently, it is also not listed in the PDF bookmarks, AKA content directory.

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

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

Must be int, not boolean

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

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

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

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

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

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)

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.