Hallo

QRK verwendet UTF8. Das DEP ist wohl nicht betroffen da hier ausser der kassenid kein Text codiert wird.

Ich verstehe es noch nicht ganz und sammele noch alle Info.
Es kommen Meldungen das es Problemen gibt mit dem DEP.
Was QRK über JSON bekommt, ist so zu sehen nicht OK.

Normalerweise läuft alles bei mir auf UTF8, ich kontrolliere es noch.

MfG
Jan

Servus,

der "Export" aus Chromis ist nicht in UTF8 kodiert, daher kommt das Problem. Im täglichen Betrieb ist mir aber noch kein Problem aufgefallen.

Ich habe im Frühjahr das bon2json-Shellskript in Python umgeschrieben und mit einem Zeichensatz-Umwandler versehen, aber dann nie eingesetzt. Ich kann das Skript nächste Woche gerne auf Github dazuhängen.

Grüße, Stefan

Danke Stefan,

wäre es evt. möglich früher per pm zu schicken, der Nutzer ist ein wenig nervös.

Ich gehe heute noch da.

MfG
Jan

Servus,

die zerstörten Umlaute sind nicht schön, im Jahr 2017 sollte die IT das schon hinbekommen. Alternativ tun es auch ae, oe, ue und ss. Aber es stimmt schon, auch eine schöne Rechnung gehört zum Image eines Unternehmens.

Hier der Entwurf des Python-Skripts (readpipe.py), sollte mit Chromis und POSper (epson-Drucker wie angegeben) funktionieren.

https://github.com/stefankugler/print-qrk-json

Fehlerkorrekturen nehme ich gerne vor.

Grüße, Stefan

Danke Stefan,

ich werde es heute drinnen bringen.

Ja, UTF8 schon mehr als 20 Jahren da.
Gestartet 1992.
Noch immer nicht überall richtig implementiert sehe z.B. Mysql . .

MfG
Jan

Hallo Stefan,

in dem pythonscript muss als 1. Zeile noch
#!/usr/bin/python
gegeben werden, das ist aber nicht so wichtig.

Ich bekomme leere Dateien obwohl der Terminal die Daten richtig anzeigt, wie hier

Opening FIFO...
FIFO opened
Writer closed
Opening FIFO...
FIFO opened
{"receipt":[{"customerText": "1339","payedBy": "0","items":[ { "count": "1","name": "1/3 Bier","gross": "2.8000000000000003", "tax": "20.0" },{ "count": "1","name": "1/3 Bier","gross": "2.8000000000000003", "tax": "20.0" }]}]}

Writer closed
Opening FIFO...

Es ist ein Testumgebung auf Kubuntu 16.04 mit Chromis und QRK.
Könntest Du bitte noch mal schauen?

MfG
Jan

Es gibt noch ein zusätzliches Problem.
Wenn ich Produkte mit Mengen-Angabe von Chromis in QRK schicke dann kommt
es vor dass die Menge "0,9" ist, QRK erwartet aber offensichtlich "0.9".
In QRK wird die Menge 0 und Preis auch 0.

Komischerweise sind alle Preisangaben mit Punkt wie "12.80".

Das kann man umgehen in Chromis mit der zu berechnen Einheit,
z.B. nicht 0,9 m aber 9 dm.

MfG
Jan

Es betrifft Komma mit denen JSON-Formatierung Problemen hat.

Servus,

mit dem Zeichensatz bin ich noch dran, bei mir funktioniert das Python-Skript inkl. Dateiausgabe.

Als Alternative geht ev. auch im bon2json.sh einfach statt dem

mv "$qrkpath/bon.txt" "$qrkpath/$now.json"

ein

iconv -t 437 -f utf-8 -o "$qrkpath/$now.json" "$qrkpath/bon.txt"

Gelegentlich kommt es da aber bei QRK zu einem Importfehler, den ich mir noch nicht erklären kann.

Grundsätzliches Problem an der Sache: Die POS-Drucker-Ausgabe ist Codepage 437 (vgl. Quellcode Chromis auf github, nach 437 suchen), Umlaute gehen, ein scharfes s kommt in diesem Zeichensatz aber nicht vor. Das wird immer ein Fragezeichen. Auf gut Glück könnte man alle Fragezeichen in ß umwandeln, wenn keine weiteren Sonderzeichen in den Produktbezeichnungen vorkommen. Ev. kann man das in QRK besser lösen und dort einen Konverter einbauen. Option in den Einstellungen: "Servermodus: Zeichensatz Importdatei, Dropdown CP437 oder UTF8".

Die Sache mit dem Punkt/Komma in der Mengeneinheit habe ich über das Chromis-Druckertemplate gelöst. Siehe

https://github.com/stefankugler/print-qrk-json/blob/master/Printer.Ticket.chromis

Dazu wurde auch schon ein Issue gepostet und der reguläre Ausdruck angepasst.

Grüße, Stefan

Danke Stefan,

das bringt uns weiter, ich suche gerade wie ich mit Hilfe der Codepage und Bash
die richtige Zeichen übergeben kann an QRK.
Ich dachte es ist cp850 - habe bei mir alle Locales kontrolliert und suche ob es in
Bash zu lösen wäre mit lang=[ein locale] oder eine andere art (export) um der Locales-Einstellung
nur innerhalb dem Script zu ändern so dass es in der JSON-Datei richtig ankommt.

Ich habe das ganze bei mir installiert.

Danke für die Punkt/Komma Lösung.

MfG
Jan

Lieber Jan,

ich habe einen Featurewunsch für den Zeichensatz gepostet:

https://www.ckvsoft.at/forum/qrk-feature-request/zeichensatz-fuer-json-import-und-ev-storno-per-json/

Grüße, Stefan

Hallo

Zu Punkt/Komma war ich der Meinung das schon behoben zu haben. Ein Blick in den Code hat mir allerdings gezeigt das ich wohl die Menge (count) vergessen habe.  Es funktioniert nur fur gross und net. Ich werde das beheben.

Danke für eure Bemühungen, ich kann so der Nutzer wieder auf dem richtigen Spur helfen.

Ich werde das mit iconv bei mir (und der Nutzer) mal weiter testen.

MfG
Jan

Hallo Stefan und Chris,

Mit iconv drinnen bekomme ich folgende Fehler, der JSON-Datei bricht ab bei der erste Umlaut
Meldung im Terminal
iconv: ungültige Eingabe-Sequenz an der Stelle 31

Ich habe nach dem Vorbild mit dem Komma PrinterTicket angepasst wie folgt

------------------------
{ "count": "
#set ($mengeKomma = ${ticketline.printMultiply()})
#set ($mengePunkt = $mengeKomma.replace(",", "."))
${mengePunkt}
",
"name": "
<!-- ${velocityCount} von ${anzahl} -->
#set ($textreplace=${ticketline.printName()})
#set ($textreplace1 = $textreplace.replace("ä", "ae"))
#set ($textreplace2 = $textreplace1.replace("ö", "oe"))
#set ($textreplace3 = $textreplace2.replace("ü", "ue"))
#set ($textreplace4 = $textreplace3.replace("ß", "ss"))

$textreplace4
",
"gross": "
---------------------------

ist vielleicht nicht schön aber funktionell.

Frage an Stefan, mit #set kann man vieles erreichen, welche Funktionen ausser
"replace" kann man nutzen, wo ist der Dokumentation?

LG
Jan

Servus,

das Ersetzen in den Templates geht natürlich auch, aber wenn schon ae/oe/ue/sz, dann kann man ja gleich die Produktbezeichnungen anpassen. Oder Chromis anpassen, dass es den Schritt UTF8->IBM437 auslässt.

Die Templates sind mit Apache Velocity "programmiert", das ist eine Java-basierende Template-Engine:

http://velocity.apache.org/engine/1.7/user-guide.html

Oder per Velocity ein Replace von ä in z.B. #ae# und per bon2json.sh/sed von #ae# -> ä. Dann gingen alle Umlaute/Sonderzeichen, wenn man sie manuell codiert.

Ad iconv-Fehler: Hänge einmal eine Json-Datei (als Anhang) hier an oder mach ein Issue bei Github mit der Datei auf.

Grüße, Stefan

Hallo Stefan,

es ist nicht so wichtig, nur müssen die Umsätze in beide Stimmen.

Wo es velocity betrifft, ich versuche in Chromis MWSt und Summe inkl. MWSt zu berechnen für
Printer.PreviewTicket das klappt, nur runden geht nicht oder Summe mit 2 decimal Positionen.
Ich bekomme z.B. MWSt. 1.5000000000000002 und Summe 9.0 alles was ich bis jetzt versucht habe
funktioniert nicht, es sieht so aus als ist velocity nicht komplett installiert.

Hast Du ein Idee?

Weiter bekomme ich auf der Kassenbon von QRK das Chromis-Ticketnummer aber keine Text vor dem Nummer.
Ich habe "customerText" in "Rechnung" geändert, dann kommt auch kein Chromis-Ticketnummer mehr.

Wenn ich als Kopfzeile in QRK kommt das zentriert. Was kann ich da noch ändern?

PS. Das ganze funktioniert erstaunlich gut! Meine Achtung!

MfG
Jan

Servus,

kannst du das Problem mit der MWST nochmals erklären?

Für die Signatur ist ja nur der Brutto-Betrag der einzelnen Produkte inkl. Steuersatz relevant, die Registrierkassa soll ja nur den Umsatz zählen. QRK und POS stimmen brutto centgenau überein.
Wo willst du da eine Mwst berechnen? Die Buchhaltung macht mein Kunde über den Kassenabschlag vom POS.
Hänge ev. einmal ein Foto oder einen Screenshot an.

Einen Text vor die Rechnungsnr müsstest du mit

<text>{"receipt":[{"customerText": "TEXT VOR DER RECHNUNGSNR ${ticket.printId()}","payedBy": "0","items":[

bekommen. customerText ist der Name der Variable und darf nicht geändert werden. Groß- und Kleinschreibung beachten!

Grüße, Stefan

Hallo Stefan,
es geht nicht um den Signatur, das macht QRK problemlos.
Rechnungnummer als Text drinnen funktioniert schon, Danke!

Es geht um ein Preview vom Ticket in Chromis dass nur zur Kontrolle genutzt wird.
Das selbe werde ich nutzen für eine Verbindung mit Frontaccounting.
Da berechne ich selber im Ticket wieviel Umsatz pro Steuerkategorie und wieviel Steuer im Summe Steckt,
das funktioniert, nur kann ich es in Chromis nicht so richtig gestalten.

MfG
Jan

Servus,

die Werte kannst du ja auch direkt aus Chromis abgreifen:

https://github.com/ChromisPos/ChromisPOS/blob/master/src-pos/uk/chromis/pos/templates/Printer.Ticket.xml#L183-L190

Grüße, Stefan

Nein, das geht nur wenn eine Rechnung abgeschlossen wird mit "="
bei einem Preview sind diese doch noch nicht gespeichert.

Ich lasse mich gerne des besseren belehren denn direkt aus Chromis heisst
korrekt formatiert.

MfG
Jan

Servus,

das dürfte ein Bug sein:

https://code.openbravo.com/pos/devel/pi/rev/f24c6f2c173f05faccfdc5dbc5e70aceb42f28d7

Der relevante Chromis-Code:

https://github.com/ChromisPos/ChromisPOS/blob/a0c6c70f694d3fa5a97817d3cdccae348c09989c/src-pos/uk/chromis/pos/sales/JPanelTicket.java

Grüße, Stefan

Obwohl nicht ganz ordentlich funktioniert es

## round up to 2 digits:
#set($vat1 = $vat1 + .005)
## truncating is same as Math.Floor at this point:
#set($endi1 = $vat1.toString().indexOf('.') + 3)
#set($vat1=$vat1.toString().substring(0, $endi1))

So bekommt man statt MWSt. 1.5000000000000002 und Summe 9.0
ordentliche 1.50 und 9.00

MfG
Jan

In javascript geht das wohl mit toFixed();

var num = 5.56789;
var n = num.toFixed(2);

In java sollte man BigDecimal verwenden. In Cpp gibt es das leider nicht. Da bin ich auf der suche nach einer funktionierenden Version