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.