Skip to content

Preview

Martin edited this page Jun 6, 2023 · 54 revisions

The next release shall contain support for device class PointCardRW to complete support for all device classes specified in UPOS 1.15.

In addition, all device classes supported by jpos 1.15 will be prepared to work with jpos 1.16 as well. Therefore, a specific jar file - Jpos116Dummy.jar - will be provided: It will contain a JavaPOS 1.16 implementation for device classes Lights and POSPower as well as the corresponding interfaces LightsConst and POSPowerConst. Until an official implementation for jpos 1.16 becomes available, this should be enough because Lights and POSPower are the only device classes that have been changed since jpos 1.15.

To ensure that these implementations override the corresponding implementations of jpos1.15, this jar file must be within the class path before the jpos 1.15 jar file. When an official jpos 1.16 jar file will be available, Jpos116Dummy.jar should be removed from the class path.

Validation concept for POSPrinter, LineDisplay and PointCardRW has been changes slightly.

Due to a conversation with several members of OMG (Object Management Group, the UPOS standardization organization), it remains vendor specific how string representations of currency values must be made. For OPOS and POS for .NET, the situation seems to be clear: The string representation of 123.45 is "123.45" (perhaps with additional trailing zeroes). For JavaPOS, the situation is a little bit different: A Currency value of 123.45, stored within a variable of type long, is represented by a long value of 1234500. Therefore, some vendors provide a string representation of "1234500" for the currency value 123.45, while other vendors use the same string representation as OPOS and POS for .NET - "123.45" (perhaps with additional trailing zeroes).

This seems to be only a problem within FiscalPrinter class devices (for CAT and ElectronicValueRW, string representations always represent the currency value, not the internal integer representation), therefore only a few new methods will be added to FiscalPrinterInterface that allow easier data exchange between the corresponding service and the device implementation: getData with data parameter of type long[] to store currency values and of type int[] to store numbers or counters, getTotalizer with data parameter of type long[] to store currency values and printRecPackageAdjustment and printRecPackageAdjustVoid with additional parameter parsedAdjustments of type Map<Integer,Number> which holds the adjustment amounts with the corresponding vat ids as key. Even if default implementations exist for backward compatibility, it is strictly recommended for implementations based on JavaPOS-SPF to use the new methods to avoid problems due to miss-interpretation of currency values passed in strings.

Even if all these changes require only little changes in existing driver implementations, this is reason enough to increment the minor number in next release.

Clone this wiki locally