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.

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.

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

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.

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

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

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

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"

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

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.

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

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.

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

Improved StatusUpdateEvent values and description in Remarks

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

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

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.

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

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.

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:

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

Issue Group F

Remarks in bar doc:

P116
P132
P133
P149
P168
P181
P182
P199
P221
P235
P236

Added missing method conditions for UPOS1161-8

See attached spreadsheet for extent of modifications.

Example:

42/ Voice Recognition
ClearInput Method,
ClearInputProperties Method

Added: void:

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

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.

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

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.

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

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.

UPOS 1.16 RCSD proposed 9 new devices but compare to the current UPOS specifiation it nees the more detailed device behavir explanation compare to the current UPOS1.15 specfication.

*All of required correction and editing was completed. *

Based on the suggestion and discussion about the UPOS 1.16 RCSD specification, issue editing and to make the document history to identify all of the changes from current one to new one was completed.
Also, regarding the class diagram changing history was included.
Please refer to the attached revised with history type UPOS 1.16 RCSD specification.

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

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.

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

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.

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

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.

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

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.

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

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.

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

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.

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

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.

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

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

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.

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

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.

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.

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.

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.

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.

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

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.

UPOS-3 is is duplicate of UPOS-1

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

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.

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.

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.

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.