Hallo

Die Bezahlart "Gutschein" gibt es nicht. Das muss auch unterschiedlich gehandelt werden. Es gibt ja unterschiedliche Gutscheine.

Wertgutschein: ist beim Kauf ein Zahlungsmittel, daher kein Barumsatz. Darf freiwillig im 0% Steuersatz signiert werden, muss im 0%-Steuersatz mitgeführt werden, wenn gemeinsam mit anderen Artikeln verkauft. Einlösung = Zahlungsmittel wie Bargeld.

Leistungsgutschein: USt beim Verkauf = Barumsatz, bei Einlösung kein Barumsatz.

Servus,

ich beziehe mich auf den Wertgutschein. Die steuerliche Handhabung ist mir klar, es geht mir nur um die korrekte Darstellung der Barumsätze beim Tagesabschluss. Dort werden ja Kreditkarte und Bankomat auch extra dargestellt, hier wäre eben "Gutschein" auch noch hilfreich.

Der Warengutschein ist kein Problem, hier "fehlt" ja kein Bargeld.

Grüße, Stefan

Ich würde gerne dieses Thema nochmals aufgreifen. Inzwischen ist es wieder aktuell, wir wollen Wertgutscheine der Region annehmen.

Praktisch hätten wir noch die Zahlart Kreditkarte über (bargeldlos läuft alles über Zahlart Bankomat), das schaut am Bon aber blöd aus. Zugriff per Servermodus ist für uns auch relevant (im Hintergrund läuft ChromisPOS).

Gerne gegen Rechnung. Den RFID-Reader lasse ich dir gerne zukommen (anderer Thread), aber damit hast du ja auch wieder nur Arbeit 🙂

Danke!

Stefan

Hallo @stefaan,

vielen Dank, dass du das Thema nochmals aufgegriffen hast. Es freut mich zu hören, dass ihr jetzt Wertgutscheine aus der Region annehmen möchtet. Das passt perfekt, denn seit Version 1.24 haben wir für die PRO- und GASTRO-Versionen unser Gutscheinmodul erweitert.

Mit dem aktuellen Update wurde das Modul um die Unterstützung für 3rd Party Mehrzweckgutscheine erweitert. Ihr könnt also problemlos regionale Wertgutscheine integrieren und es ist auch möglich, Mischzahlungen zu verarbeiten. Außerdem ist die Zahlart "Gutschein" bereits vorhanden, sodass klar ersichtlich ist, wenn mit einem Gutschein bezahlt wurde.

Bezüglich des RFID-Readers: Ja, du hast recht, besonders für Windows ist es mehr Arbeit als erwartet. Daher werde ich das erstmal weglassen.

payedBy und secondPayedBy im Json wurde um die Bezahlmöglichkeit Gutschein erweitert

payedBy
secondPayedBy

0 = BAR, 1 = Bankomat, 2 = Kreditkarte, 3 = Gutschein

Lieber Chris,

herzlichen Dank für die Erweiterung, Gutschein als Zahlung mit id 3 funktioniert. Das hatte ich gestern nach kurzem Blick in den Quellcode einfach ausprobiert. Achtung: Wenn man die ids weiter hochzählt, kommt dann Tagesabschluss (4) oder Monatsabschluss (5) als Zahlungsart. Das sollte wohl nicht so sein (aber wer würde das schon tun :D).

Bei gesplitteten Zahlungsarten erscheint bei meinem Test aber nur eine Zahlungsart auf der Rechnung (zumindest im PDF). Im Rechnungsjournal erscheinen mehrere Zeilen und Mischzahlung, aber da ist auch nicht ersichtlich, wie viel mit welcher Zahlungsart bezahlt wurde.

Ich habs aber noch nicht weiter systematisch ausgetestet (bis zum Tages/Monatsabschluss).

Version 1.24.9 unter Mint mit Importserver.

Stefan

@stefaan 
Hallo
Sollte alles in der aktuellen 1.24.10 gefixed sein.
Bei der 1.24.9 war das noch nicht geplant. Das war wohl auch vorher schon so weil die bazahlart nicht überprüft wurde.

Wow, das ging ja schnell.
Neben ID 4 und 5 kommt aber auch bei 3 jetzt die Fehlermeldung, dass es sich um keine gültige Bezahlart handle!
Stefan

Veröffentlicht von: @stefaan

↑

Wow, das ging ja schnell.
Neben ID 4 und 5 kommt aber auch bei 3 jetzt die Fehlermeldung, dass es sich um keine gültige Bezahlart handle!
Stefan

Damit die Zahlart "Gutschein" per Importserver funktioniert, muss das Gutscheinmodul aktiviert sein (obwohl es nur um die Zahlart geht und keine Gutscheine durch QRK verwaltet werden).
Alles bestens.

@stefaan 
Ja. Ich muss mir das noch ansehen. Du hast Recht. Zur Zeit werden im Servermode die Gutscheine aus QRK nicht berücksichtigt.
Ich muss aber erst noch checken wie sich die Bezahlart ohne Gutscheinmodul auf den Rest vom Ablauf auswirkt. Es werden Routinen des Moduls verwendet. Evtl. kann ich das im Servermode noch anders lösen, zumindest für 3rparty Gutscheine die nicht im Modul erfasst wurden.

Lieber Chris,
das integrierte Gutscheinmodul benötige ich ja gar nicht, wir brauchen nur eine weitere Zahlungsart.
Es würde für den Importserver schon reichen, wenn es ein paar benutzerdefinierte Zahlungsarten-IDs gibt (z.B. 11 eigene Gutscheine, 12 Gutscheine Region, Benennung über die ini-Datei) und die Zahlungsart auf den Auswertungen für die Buchhaltung unterschieden werden kann. Durch die Registrierkassa muss sowieso alles.
Stefan

@stefaan 

Hallo,

so einfach ist es leider nicht. Es sind keine Zahlungsarten über 3 möglich. Das war nie vorgesehen und es war bereits viel Arbeit, die 3 als Zahlungsart für das Gutscheinmodul frei zu bekommen.

Als ich die Kasse programmiert habe, stand die RKSV im Vordergrund. Mehr war nie angedacht. Werte kleiner als 0 sind Freibeträge für die Gastronomie, und Werte größer als 3 betreffen den Tagesabschluss bis hin zum Schlussbeleg. Um das zu ändern, müsste der gesamte Code bis hin zur Datenbank und den Einträgen umstrukturiert werden. Das werde ich für ein Gratisprodukt sicherlich nicht tun.

Wie Du sicher bemerkt hast, werden in der Open-Source-Version nur Fehler behoben und fast keine neuen Funktionen hinzugefügt. Dafür gibt es die Pro- und die Gastro-Version. Zu dieser Entscheidung bin ich schon vor einigen Jahren gekommen, da das Spendensystem einfach nicht funktioniert hat.

Eigentlich tut es mir fast leid, die Importvariante nicht in ein Modul verschoben zu haben. Dafür hat damals eine Firma viel Geld bezahlt. Ich finde, dass die 49 Euro im Jahr eh mehr als fair sind. Andere Kassen verlangen diesen Betrag im Monat.

Lieber Chris,

wenn es nur eine Gutschein-Option gibt, dann ist es für uns auch ausreichend. Gerne auch nur in der Pro-Variante, ich glaube, sie wurde auch aktiviert (mache in diesem Bistro die IT nebenbei ehrenamtlich und viel läuft über Fernwartung, ich sehe die Kassa zum Glück sehr selten).
Hier wurde historisch alles um ChromisPOS gebaut (Küchendrucker, Buchhaltungsexport) und QRK läuft für die korrekte RKSV mit. Kommerzielle Kassen-Software mit diesen Funktionen wären entweder unverhältnismäßig teuer oder bieten die Funktionen nicht in der Form.

Für ein anderes Projekt (Textilreinigung mit Filialbetrieb) hätte sich eventuell eine Option ergeben, da war dann aber durch eine webbasierende Lösung eine Kassa per REST-API notwendig und die kostet mehr als die €49/Jahr.

Stefan

Veröffentlicht von: @stefaan

↑

Lieber Chris,

Hier wurde historisch alles um ChromisPOS gebaut (Küchendrucker, Buchhaltungsexport) und QRK läuft für die korrekte RKSV mit. Kommerzielle Kassen-Software mit diesen Funktionen wären entweder unverhältnismäßig teuer oder bieten die Funktionen nicht in der Form.

Du kannst Dir ja mal die QRK Gastro ansehen, die kostet 149.- / Jahr.