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.

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.