Hyperlinks


Mit Version 1.4.2 werden die wichtigsten Infrastruktur-Komponenten von Amadeus II aktualisiert. Vor allem bei MySQL kann dies bis zu 30 Minuten in Anspruch nehmen. Die absolut kritischen Punkte für das Update: 

Bitte unbedingt vor dem Update lesen und beachten!

  • Unbedingt vorher ein Backup des gesamten Amadeus II - Verzeichnisses anlegen. Der vorgeschlagene Weg wird hier beschrieben.
  • Je nach Größe der Datenbank sollte für das Update zwischen 30 Minuten und 1,5h eingerechnet werden. In dieser Zeit kann die Kasse nicht benutzt werden. 
  • Sobald das Update begonnen wurde darf es unter keinen Umständen abgebrochen werden. Vor allem das Aktualisieren von MySQL ist extrem kritisch was Unterbrechungen anbelangt. Wird ein Update unterbrochen hilft nur das Zurückspielen des Amadeus II Ordners. Abgebrochene oder unterbrochene Updates können nicht repariert werden. 
  • Gleiches gilt für den ersten Start des Tomcat-Server nach der Aktualisierung. Nach dem ersten Start des Tomcat-Server wird die Datenbank an die Struktur von 1.4.2 angepasst. Während dieser Zeit dürfen MySQL und Tomcat nicht beendet oder neu gestartet werden. Wann der Update-Prozess abgeschlossen ist erkennt man am einfachsten über den Taskmanager. Sowohl der Tomcat-Prozess als auch der MySQL-Prozess dürfen im Leerlauf maximal 1% der CPU-Leistung belegen. 
  • Das Update auf 1.4.2 ist aufgrund der Infrastruktur-Updates nur über den Installer verfügbar. Auf diese Weise ist sichergestellt, dass alle Komponenten gemeinsam installiert werden und alle Abhängigkeiten erfüllt werden. 
  • Alle Komponenten von Amadeus II 1.4.2 sind nicht abwärtskompatibel oder dürfen gemischt werden. Server, Reporting, Sol-Dienst und ATouch II müssen alle den gleichen Versionsstand haben. Auch diese Voraussetzung wird durch den Installer/Updater/CP überwacht. 
  • Zudem ist wichtig, dass der Updater bei großen Datenbanken, bei dem Punkt "Registry konfigurieren" im letzten Update Schritt etwas länger als gewohnt stehen bleiben kann. Der Updater hängt in diesem Fall nicht, sondern führt im Hintergrund entscheidende Update Prozesse durch. Bitte keinesfalls abbrechen!


Die oben genannten Punkte sind kritisch für dieses Update. Werden diese Punkte nicht eingehalten kann die Gastro-MIS keinen Support für defekte Installationen übernehmen. 


Auch mit Version 1.4.2 gilt: Updates werden nur noch mit Hilfe des Amadeus II Control Panel Updaters durchgeführt. Bitte hierzu nachfolgende Anleitung berücksichtigen: Updater

Zudem bitte darauf achten, dass Java 8 Runtime (32bit) installiert ist.


Breaking Change

Wenn keine gültige Lizenz gesetzt ist, dann kann man ab sofort im Backoffice keine Artikelstammdaten mehr bearbeiten und kann sich im Reporting nicht mehr anmelden!

  • Ist der Lizenzstatus "CONFIRMED" oder "WATCHLISTED", kann das System ohne Einschränkung genutzt werden. Man muss jedoch beachten, dass der Lizenzstatus "WATCHLISTED" ein Ablaufdatum besitzt. Ist die Lizenz bis dahin nicht zurück auf "CONFIRMED" gesetzt, so geht diese im nächsten Schritt in den Status "UNTRUSTED", was zur Folge hat, dass keine Anmeldung im Reporting mehr möglich ist und auch keine Stammdaten im Backoffice mehr bearbeitet werden können!
  • Ist der Lizenzstatus "NOTSET" oder "UNTRUSTED", dann kann man sich nicht mehr im Reporting anmelden! Es erscheint die Fehlermeldung "Lizenzfehler" beim Versuch sich anzumelden. Zudem ist beim Status "UNTRUSTED" keine Artikelstammdatenpflege im Backoffice möglich. 

WICHTIG: Ist die Lizenz aufgrund von z.B. zu viel Terminals auf "UNTRUSTED", so kann nur durch den Lizenzstatus "NOTSET" die unnötigen Geräte deaktiviert werden! Sind hingegen zu wenige Geräte Lizenziert, so reicht es, wenn die fehlenden Geräte im Lizenzportal hinzugefügt werden (ACF Neustart nicht vergessen).


            Die ATouch 2 setzt alle neuen Funktionen im Server um, darunter vor allem auch den Faktor bei der                             Änderung einzelner Artikel. Außerdem wurden in der Version 1.4.2 folgende neue Funktionen eingeführt: 

  • Neuen Kellner-Schlüssel direkt anlegen: Über die ATouch 2 kann jetzt ein Kellner-Schlüssel direkt angelegt werden. Dazu ist kein Kopieren des Schlüssels ins Backoffice mehr nötig. Dazu muss dem Kellner ein PIN vergeben werden. Anschließend meldet man sich mit diesem PIN an, legt den Befehl "SET KEY" auf einen dynamischen Button, klickt diesen an und legt den Schlüssel auf das Schloss. Schon ist der Kellner-Schlüssel registriert. 
  • Während die ATouch 2 startet wird das neue Amadeus360 - Logo angezeigt.
  • Der Anmeldestatus des Kellners wird alle 5 Sekunden überprüft und der Kellner ggf. abgemeldet, z.B. beim Tagesabschluss
  • Wird bei Menüzusammenstellungen eine falsche Eingabe gemacht, wird dies sofort angezeigt, nicht erst beim Abschicken. 
  • Die Anzahl der MEC-Code Zeilen kann definiert werden (1-8 Zeilen).
  • Das Blättern der MEC-Codes findet nun seitenweise statt.
  • In der Konfiguration kann ein Standard-MEC-Code festgelegt werden, welcher beim Öffnen eines Tisches automatisch geöffnet wird.


Mit Version 1.4.2 erhält das Reporting einen Geschwindigkeits-Turbo. Gleichzeitig fallen alle Aufgaben, welche Daten verdichtet haben und bisher täglich ausgeführt werden mussten weg, z.B. Tender oder "Big Data". Die Anzahl der täglichen Aufgaben reduziert sich somit erheblich. Auch werden mit dem Update auf 1.4.2 alle nicht mehr benötigten Tabellen aus der Datenbank entfernt, was die Datenbankgröße zwar nicht verringert, es dauert aber eine Zeit, bis sie weiter anwächst (MySQL gibt einmal belegten Speicher nicht frei sondern "behält" diesen und speichert die nächsten Daten in diesen freigewordenen Speicherplatz).

  • Berichte

Sämtliche Berichte wurden überarbeitet und haben individuelle Datenbankabfragen bekommen. Dadurch konnte die Geschwindigkeit der Abfragen um bis zu einem Faktor 20 im Vergleich zu den bereits verdichteten Berichten (Big Data) gesteigert werden. Dies wurde für jeden Bericht einzeln durchgeführt, so dass jetzt auch Zeitzonenberichte oder Tendercorrelationen über längere Zeiträume möglich sind. Gleichzeitig wurden einige Berichte in punkto Optik verbessert. Weitere Verbesserungen die Berichte betreffend:

  • Monatliche Berichte können nun auch per Mail verschickt werden. 
  • Der Artikelbericht pro Kellner wurde um Artikel erweitert, die keinen Preis haben. 
  • Gutscheinberichte weisen jetzt Summen mit aus.
  • Bericht "offene Tische bei Tagesabschluss" hinzugefügt.

  • Monitoring

Die wichtigste Änderung im Küchen/Schankmonitoring hängt mit einer Änderung im Server zusammen. Menüzusammenstellungen können pro "Gang" jetzt auch wirklich in einzelne Gänge geschoben werden. Wird also ein Menü mit den entsprechenden Einstellungen (Bitte im Bereich "Server" nachlesen) boniert, so werden die einzelnen Gänge auch im Monitoring separat dargestellt und können separat abgerufen werden (siehe Konfiguration Menü Konfiguration und Abschnitt "Menüsteuerung pro Gang" unter Steuerung im Hauptbildschirm).

Weitere Änderungen im Monitoring:

  • Die Zeiten bei Gängen werden jetzt mit dem Abrufen des Ganges (Ändern auf "in Arbeit) wieder zurückgesetzt.
  • Man kann explizit definieren, welche Preislevel auf dem Monitor angezeigt werden sollen.
  • Die Serverzeit wird an die Monitore übertragen, somit ist es nicht mehr nötig, die Systemzeit auf den einzelnen Monitoren zu setzen. Größere Abweichungen der Systemzeit auf den Monitoren von der Server-Systemzeit kann aber zu Problemen in der Kommunikation mit dem Apache Webserver führen.

  • Abholmonitore

Eine völlig neue, experimentelle Funktion in 1.4.2 sind die Abholmonitore. Abholmonitore kennt man von größeren Fast-Food-Ketten in jüngster Zeit. Der Usecase ist, dass man bei Bestellung an einer Checkout-Kasse eine Bestellnummer auf seiner Rechnung bekommt. Diese Bestellnummer wird dann auf dem Abholmonitor, welcher für den Gast sichtbar ist, dargestellt, sobald der/die Tisch/Bestellung im Monitoring als erledigt markiert ist. Somit erhält der Gast ein Feedback und kann am Abholschalter seine Bestellung abholen. Diese Funktionalität ist experimentell in 1.4.2 und wird nur unterstützt, wenn sie nach Rücksprache mit der Gastro-MIS eingesetzt wird.

Konfiguriert wird das Abholmonitoring am einfachsten, in dem man Chrome bereits bei Start die URL und den Vollbildmodus mit gibt. Als Basis dient der Hauptmonitor, auf dem auch alle Artikel, die abgeholt werden sollen, dargestellt werden.

Der Aufruf im Autostart könnte also, wenn der Hauptmonitor die Seriennummer 9001 hat und der Pin zum anmelden 999 ist, folgendermaßen aussehen:

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --start-fullscreen --app=http://backoffice.vm/monitor/index/login/sno/9001/user/999/abhol/1

Chrome im Vollbildmodus starten

Damit Chrome direkt im Vollbildmodus startet, darf er vorher auf demselben Rechner nicht geöffnet sein. Wird, wie oben beschrieben, die Option --start-fullscreen verwendet, so kann man den Vollbildmodus mit F11 beenden. Nimmt man stattdessen --kiosk, so kann der Vollbildmodus nicht beendet werden.

Der Abholmonitor Zielt auf die beiden Stati "INZONE" (also boniert) und "SERVZONE" (also am Servicepass). Somit sollte der Workflow die Stationen Boniert => Servicepass => Fertig haben. Der Arbeitsablauf vor Ort ist dann so gedacht, dass die Abholnummer auf der Rechnung des Kunden gedruckt wird. Die Artikel auf dem Monitor werden zubereitet und wenn die gesamte Bestellung fertig ist wird der Tisch auf "Servicepass" gestellt. Der Gast holt seine Bestellung ab, und der Tisch wird auf "fertig" gestellt. Für einen Reibungslosen Ablauf sind also (mindestens) 3 Monitore und 2 Lizenzen nötig: Hauptmonitor in der Produktion (1 Lizenz), Monitor an der Abholstation (1 Lizenz, sollte ein anderer Monitor sein, damit die Artikel auf dem Produktionsmonitor ausgeblendet werden können, wenn auf dem Pass) und ein Abholmonitor, der auf den Monitor an der Abholstation geht und somit keine Lizenz benötigt. Der Abholmonitor kann nicht auf den Produktionsmonitor gehen, wenn dort die Artikel ausgeblendet werden, sobald sie an der Ausgabe stehen. 

  • Neustart Soldienst

Da der Neustart des Sol-Dienstes in Windows 10 nicht mehr per rdp ausgeführt werden kann, gibt es im Reporting jetzt die Möglichkeit, den Sol-Dienst neu zu starten. Voraussetzung dafür ist, dass

  • Apache und Sol-Dienst auf dem gleichen Server laufen,
  • Amadeus II über den Installer installiert wurden und somit die Dienste die Standard-Namen haben. 


  • Wechselgeldeingabe und Kellnerselbstabrechnung

Mit 1.4.2 kann in den Kellnerrollen die Wechselgeldeingabe sowie die Kellnerselbstabrechnung verpflichtend eingestellt werden. Ist dieses "Recht" gesetzt, so wird der Kellner beim ersten Öffnen eines Tisches nach dem Wechselgeldbestand gefragt. Der Kellner kann während seiner Schicht keinen Kellnerabschlag erzeugen, weiß also nicht, wie viel Geld in der Kasse/Geldbeutel vorhanden sein muss. Wird am Ende der Schicht die Kellnerabrechnung angefordert, so wird der Kellner aufgefordert den Bargeldbetrag, welcher in der Kasse vorhanden ist einzugeben. Erst danach wird die Kellnerabrechnung gedruckt. Auf der Kellnerabrechnung wird sowohl der Wechselgeldbestand vom Anfang, der eingegebene Zählbetrag als auch die Differenz zur tatsächlichen Bargeldverpflichtung ausgegeben. Die Differenz ist entweder Trinkgeld, oder ein Fehlbetrag, je nach Vorzeichen. 

Siehe Anleitung: Wechselgeldeingabe und Kellnerselbstabrechnung

  • Management-Tool

Im Management-Tool ist das Löschen des Tagespeichers nicht mehr möglich. Dies ist zum einen Grundvoraussetzung für die Österreichische Sicherheitseinrichtung, zum anderen wurde diese Funktion in der Vergangenheit zu oft irrtümlich ausgeführt.

  • Gänge im Menü

Bei Menüzusammenstellungen können nun Gänge (Sortorder) definiert werden. Ist diese Einstellung getroffen, so wird das Menü nicht mehr als ein Artikel mit Tendern dargestellt, sondern als X Artikel mit Tendern in den jeweiligen Gängen. Die Darstellung erfolgt sowohl im Monitoring wie auch im Bondruck. 

Siehe Menü Konfiguration

  • Nachträgliche Änderungen am Artikel

Zwei Änderungen gibt es beim so genannten Update-Befehl:

  • Das Preislevel kann jetzt ebenfalls nachträglich, vor Absenden des Bons verändert werden. 
  • Sind mehrere, gleiche Artikel boniert kann die Änderung mit einem Faktor versehen werden, also z.B. 3 von 5 Schnitzeln in den zweiten Gang schieben.

Siehe Bonieren die Punkte "Rabattieren/Hausbon" und "Preisebene korrigieren"

  • Weitere Änderungen im Server

  • 0-Preis-Artikel verwenden: In den Betriebsparametern gibt es eine neue Option "0-Preis-Artikel verwenden". Ist diese Option aktiv, so werden Artikel, bei denen der Betriebsparameter zwar angelegt ist aber kein (0€) Preis hinterlegt ist, tatsächlich mit 0€ boniert. Bisher fielen solche Artikel immer auf die Standard-Betriebsstelle zurück. Diese Option kann z.B. für Personalpreise verwendet werden. 
  • Beim Artikel kann man nun einstellen, dass man diesen noch bonieren kann, obwohl der Kellner nur das Recht "separieren" hat und bereits Artikel auf diesen Tisch gesplittet hat. Dazu muss lediglich die Checkbox "Splitten immer erlaubt" im Artikel aktiviert werden. Anwendung findet diese Option z.B. beim Trinkgeld, das nach dem Separieren noch auf den Zieltisch gebucht werden soll. 
  • Hauptartikel die selbst keinen Preis haben, sondern der Tender den Preis darstellt, können nun auch rabattiert werden.
  • Pagernummern können jetzt auch noch geändert werden, wenn der Bon bereits gedruckt wurde. 
  • Alle Bons werden nur noch zwei Wochen im Server gespeichert (Bisher 3 Monate). Die Tabelle mit den gespeicherten Bons machte etwa 50% der Datenbankgröße aus. 
  • Die "tabletransaction.number" auf dem Bon und der Rechnung (Abholnummer) wird ab sofort mit dem Tagesabschluss auf "1" zurückgesetzt. (siehe Abschnitt "Abholnummer": Änderungen in Amadeus II Version 1.3.1)
  • Für MEC-Codes können Anzeigenummern festgelegt werden.
  • Der Stammdaten Import wurde um folgende Felder erweitert: alternative Nummern, Anzeigename und weitere MEC-Codes. Bitte bei einem Stammdatenimport zuvor einen Export einer aktuellen Liste durchführen und die entsprechenden Felder pflegen.


Mit dem Update auf Version 1.4.2 werden alle Infrastruktur-Komponenten von Amadeus II auf neue Versionen gehoben. Die Updates werden vom Control Panel/Updater automatisch durchgeführt. Aufgrund der Updates sollte man je nach Datenbankgröße allerdings 10-30 Minuten mehr einplanen als normalerweise üblich. Die Updates sind aus Performance und vor allem auch Stabilitätsgründen zwingend nötig und machen 1.4.2 damit zu einem sehr wichtigen Update.

Da sowohl Apache, Tomcat als auch MySQL auf neue Versionen gehoben werden ist es dringend zu empfehlen, vor dem Starten des Updates ein komplettes Backup des gesamten Amadeus II Ordners zu erstellen. Vorgehensweise:

  • Entweder alle Dienste über das CP anhalten oder einzeln Apache, ACF, Tomcat und MySQL (in dieser Reihenfolge!) anhalten. 
  • Kompletten Ordner, inkl. mysql, tomcat, ACF und Apache-Verzeichnis kopieren und sichern. 
  • Alle Dienstes in umgekehrter Reihenfolge wieder starten. 

  • MySQL - Datenbank

MySQL wird von Version 5.6.x auf 5.7.17 gehoben. Neben einem durchaus schon im normalen Bonieralltag spürbaren Performancegewinn ist vor allem die Steigerung der Performance im Reporting (zusammen mit den Änderungen im Reporting in 1.4.2) ein sehr wichtiges Argument für das Upgrade. Außerdem hat Oracle in Version 5.7.x viel an der Stabilität speziell in Windows - Umgebungen gearbeitet, so dass Datenbank-Crashes oder inkonsistente Datenbanken deutlich seltener vorkommen sollten. Das Upgrade der Datenbank wird durch den Installer komplett durchgeführt. Dabei wird die neue Version installiert und anschließend die Datenbank optimiert. Dieser Vorgang darf unter keinen Umständen unterbrochen oder abgebrochen werden! Nach dem Update wird der Datenbankserver durch das CP neu gestartet. Erst danach sind wieder Verbindungen mit dem Datenbankserver möglich. 

  • Tomcat - Anwendungsserver

Der Tomcat-Server wird von Version 8.0.x auf 8.5.15 aktualisiert. Hierbei steht weniger die Performance im Vordergrund als die Stabilität und einige Sicherheitslöcher, die in der Version 8.5.x gestopft wurden. Das Update erfolgt durch den Updater voll automatisch und ist innerhalb weniger Minuten erledigt. Der Tomcat-Server wird anschließend neu gestartet. 

  • Apache - Webserver

Der Apache Webserver wird auf Version 2.4.25.0 aktualisiert, was vor allem für das Monitoring einen deutlichen Stabilitätszuwachs bringt. Die Zahl der Abstürze/eingefrorenen Apache-Dienste sollte sich damit deutlich reduzieren. Das Update erfolgt durch den Updater voll automatisch und ist innerhalb weniger Minuten erledigt. Der Apache wird nach dem Update neu gestartet. 



  • Update 08.11.2017

  • Reporting Build 1165
  • [Bugfix] Report "Umsatz pro Kellner" und "Umsatz pro Kellner pro Tag" haben in den Spalten Provision und Auslagen keine Zahlen ausgewiesen. Dies wurde behoben.

  • Update 29.08.2017

  • Server Build 170829
  • [Bugfix] Beim Vorschalten von Gängen bei Menüs, im Zusammenspiel mit dem Monitoring, kam es vor, dass Bons nicht gedruckt wurden, wenn der Icon zum Weiterschieben des Artikels in die nächste Zone verwendet wurde. Das Problem wurde behoben.
  • Reporting Build 1134
  • [Bugfix] Fehler beim Handling von Menüs mit Gängen bei Vorschalten von Gängen oder Update von Gängen behoben.

  • Update 22.08.2017

  • Server Build 170821
  • [Bugfix] Beim Annehmen von Artikeln mit Faktoren im Monitoring und anschließendem einzelnen Abarbeiten, führte dazu, dass beim ersten Artikel der abgearbeitet wurde, auch die anderen Artikel gleich mit am Bondrucker ausgelöst wurden. Fehler wurde gelöst.
  • [Bugfix] Durch Bonieren des Artikels "Trinkgeld" (der mit dem Finanzweg Trinkgeld verknüpft ist) + Tender-Bonierung mit Preis und anschließendem Storno, führte dazu, dass der Umsatz des Kellners entsprechend geringer ausfällt und somit eine Außenstandsdifferenz in der Abrechnung bestand. Das Fehler wurde behoben.
  • [Bugfix] Bei Menübonierung mit "Außer Haus" Umschaltung, anschließendem Storno- und Verkaufsstellen-Umschaltung führte zu Außenstandsdifferenzen. Der Fehler wurde korrigiert.
  • Reporting Build 1131:
  • [Bugfix] An Ruhetagen, waren Reports ohne Z-Zähler und Inhalt aufgeführt. Fehler wurde korrigiert.
  • [Bugfix] Vordefinierte Zeitzonen- und Aktionsreports haben aufgrund der in 1.4.2 geänderten 15-Minuten Auswertung andere Zahlen ausgegeben. Hier wurde wieder auf die 5-Minuten Auswertung geändert. 
  • [Bugfix] Wurde ein Kellner-Filter z.B. auf den kellnerbezogenen Report "Finanzwege Artikelgenau" gesetzt, so erschien die Meldung "Es ist ein Fehler aufgetreten". Das Problem wurde gelöst.

  • Update 02.08.2017

  • Reporting Build 1119:
  • [Bugfix] Beim Setzen des Verkaufsstellen-Filter "0" kam die Fehlermeldung "Ein Fehler ist aufgetreten" zurück. Dies wurde behoben.

  • Update 26.07.2017

  • Server Build 170726
  • [Bugfix] Die Menübonsortierung wurde nicht mehr nach den einzelnen Optionen von oben nach unten sortiert. Die fehlerhafte Sortierung wurde korrigiert.

  • Update vom 24.07.2017

  • Server Build 170724:
  • [Bugfix] Die Bonnummer wurde bisher nach einem Tagesabschluss nur von 1 beginnend gedruckt, wenn auch der Tomcat neu gestartet wurde. Ab sofort wird die Bonnummer ohne Tomcat Neustart bei 1 beginnend gedruckt, sofern ein Tagesabschluss am System stattgefunden hat.
  • [Bugfix] Wurden Gänge im Menü konfiguriert, so konnten die Bons einzelner Gänge nicht gedruckt werden. Dies wurde behoben.
  • [Bugfix] Artikel die einen Tender mit Preis beinhalten, konnten zu einem Menü dazu geholt werden, wobei der Tender storniert wurde. Dies ist nicht mehr möglich. D.h. Artikel die einen Tender mit Preis beinhalten, können nicht mehr in ein Menü geholt werden.
  • [Bugfix] Bei Menüs die einen Anspruchsartikel beinhalten, konnten Artikel, die diesem Anspruch angehörten nicht separat boniert werden, sondern nur innerhalb des Menüs. Dies wurde behoben. Es erscheint jetzt eine Abfrage, ob der Artikel innerhalb oder außerhalb des Menüs boniert werden soll.
  • [Bugfix] Beim Anlegen von Angeboten in einem Artikel konnte es vorkommen, dass der Server neu gestartet werden musste, damit Änderungen übernommen werden. Der auftretende Fehler wurde behoben.
  • [Bugfix] Wurde eine Druckerumleitung eingeleitet, konnte es vorkommen, dass der nächste Drucker nicht gefunden wurde. Das Problem konnte von uns nicht nachgestellt werden, müsste nun allerdings behoben sein.
  • [Bugfix] Eine fehlerhafte Darstellung bei Artikeln mit Rabatten, wurde auf dem Bon-Artikelbericht korrigiert.
  • Reporting Build 1117:
  • [Bugfix] Wurden Tender an ATouch1 oder Leo2 storniert, so wurde der Kellner mit Name "null" im Monitoring angezeigt und der Bon blieb nach dem abarbeiten als leeres graues Fenster stehen. Dies wurde korrigiert.
  • [Bugfix] Ein Artikel, der mit einer Sortierung (Gang) boniert wurde mit zusätzlichem Tender, wurde im Monitoring angezeigt, als wären 2 Artikel boniert wurden, obwohl es sich lediglich um einen Artikel handelt. Dies wurde behoben.
  • [Bugfix] Die Dashboards haben teils nicht mehr wie gewohnt funktioniert. Problem wurde korrigiert.
  • [Bugfix] Der Report "Debitorenauswertung" wurde übersichtlicher gestaltet.
  • [Bugfix] DATEV Export ist wieder funktional.
  • Sol Build 20170718
  • [Bugfix] Wird ein Artikel boniert, der in einem bereits bonierten Menü auch als Anspruch geltend gemacht werden kann, so wird die Abfrage geöffnet, ob dieser Anspruch verwendet werden, oder der Artikel außerhalb des Menüs boniert werden soll.

  • Update vom 30.06.2017:

  • Server Build 20170629:
  • [Bugfix] Rabatt/Hausbon Summe bei Artikeln mit Faktoren wurde auf Rechnung falsch ausgewiesen. Zudem konnten sich 0-Preis Artikel auf Rechnung anzeigen und Tender mit Preis in Artikel einberechnen gegenseitig aushebeln, so dass am Ende kein Artikel auf der Rechnung angezeigt wurde. Beide Themen wurde behoben.
  • Reporting Build 1112:
  • [Bugfix] Mailversand hat nicht mehr korrekt funktioniert. Fehler wurde behoben.
  • [Bugfix] Die Reports "Zusatzverkauf pro Kellner", "Artikelliste Details - Zeitraumunabhängig" und "Debitorenauswertung" haben keine Daten zurück geliefert. Problem wurde gelöst.