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.