11.05.2023

Um mehrere Aufträge eines Kunden zu einem Lieferschein zusammenzufassen, sollen folgende Punkte zusammengefasst werden:

1. Neuer Eintrag unter Button "Workflow": "Dokumente zu Lieferschein zusammenfassen"
2. Prüfung auf gleichen Kunden & Firmierung Es dürfen nur Aufträge von einem Kunden und einer Firmierung zu einem Lieferschein zusammengefasst werden.
3. Umgang mit verschiedenen Lieferdaten in Aufträgen Analog zur Erstellung von LS aus AB sollen die im Auftrag hinterlegten Lieferdaten geprüft werden. Bei mehreren Lieferdaten in den Aufträgen & Auftragspositionen soll ein Popup mit Auswahl der Lieferdaten angezeigt werden Nur Positionen mit dem ausgewählten Lieferdatum sollen in Lieferschein übernommen werden.

Im Verkauf soll bei Erstellung von Gutschriften auf die Art hingewiesen werden:

1. Mengengutschrift oder 2. Wertgutschrift

2. Mengengutschriften müssen immer aus Retouren-Lieferscheinen erfasst werden. Die Beschriftung im Workflow aus Retouren-Lieferscheinen wird auf "Mengengutschrift" angepasst.

3. Wertgutschriften werden direkt aus Rechnungen erstellt. Die Beschriftung im Workflow von Rechnungen wird auf "Wertgutschrift" angepasst. Bei Wertgutschrift muss der EK-Preis aller Positionen auf 0,00 € gesetzt werden. Aktuell erfolgt dies nur durch Mitdenken und Korrektur des Benutzers. Durch die Automatisierung werden die Benutzer entlastet und es können weniger Fehler entstehen.

4. Info-Meldung bei Erfassung (vor Buchen) von Wertgutschriften einblenden. Text: "Sie erfassen eine Wertgutschrift ohne Retour-Lieferschein. Die EK-Preise werden in dieser Gutschrift genullt."

Der Rahmenvertrag ist in der Wirtschaft ein Vertrag, der den künftigen Abschluss vieler untereinander gleichartiger Einzelverträge zum Inhalt hat, die sich auf den Rahmenvertrag beziehen.

Aufträge sollen im ERP als Rahmen- und Abrufaufträge erfasst werden können:

1. Workflow zur Erstellung von Abrufaufträgen a) In VK- und EK-Aufträgen soll eine neue Aktion unter Workflow/Abrufauftrag vorhanden sein b) Prüfung und Frage: "Mit Erstellung eines Abrufauftrags wird der aktuelle Auftrag zu einem Rahmenauftrag. Wollen Sie fortfahren?" c) Neuer Auftrag mit allen Positionen und Verknüpfung zum Rahmenauftrag

2. Die automatische Reduzierung des Rahmenauftrags a) Jede Positions-Menge aus einem Abrufauftrag reduziert die Positions-Menge im Rahmenauftrag

   • Die Spalte "Menge" im Rahmenauftrag umbenennen zu "Übrige Menge" und soll durch Benutzer nicht änderbar sein
   • Mit jedem Abrufauftrag wird die übrige Menge im Rahmenauftrag bis auf 0 reduziert (Keine negative Menge möglich)
   • Summe der Mengen aus Rahmenauftrag & Abrufauftrag ergeben immer die ursprüngliche Summe des Rahmenauftrages b) In einer neuen Spalte "Gesamte Menge" soll die ursprüngliche Menge eingetragen werden und änderbar sein
   • Es darf keine Gesamtmenge eingetragen werden, die unterhalb der gesamten Menge in Abrufaufträgen liegt
   • Mit Änderung der Gesamtmenge wird automatisch die übrige Menge angepasst

3. Weitere Anpassungen für Rahmenaufträge: a) Button "Workflow" im hat nur den Eintrag "Abrufauftrag erfassen"

   • Lieferscheine & Rechnungen dürfen nur über Abrufaufträge erfasst werden
   • Wenn ein normaler Auftrag schon Lieferscheine oder Rechnungen hat, darf er nicht mehr zu einem Rahmenauftrag werden b) Wenn die übrige Menge in allen Positionen 0 ist, soll der Auftrag geschlossen werden c) Nicht berücksichtigen in: Bestellermittlung, Lieferwertberichte und Lieferpläne

4. Anpassungen im Auftragsbericht a) Filter nach "Auftragsart" mit Optionen "Rahmenauftrag" und "Abrufauftrag" b) Checkbox um Spalte "Auftragsart" im Bericht anzeigen zu können

Im ERP sollen Links zu Artikeln der Benutzerdokumentation in der opendynamic-Wiki eingebunden werden, die das zugehörige Feature erklären.

Als erstes sollen diese für Provisionsregeln/Vertreterabrechnung, die Inventuraufnahme und die Preisregeln zur Verfügung gestellt werden.

Der Wert aus dem Feld "EAN-Code" aus den Artikelstammdaten soll in den Artikeldetails von ERP-Dokumenten ausgegeben werden.

Der Wert soll zwischen "Beschreibung" und "Interne Bemerkung" ausgegeben werden.

Um pro Auftrag zusätzliche Informationen speichern zu können, sollen benutzerdefinierte Variablen pro Auftrag konfiguriert werden können. Diese sollen über einen neuen Reiter "Benutzerdefinierte Variablen" zur Verfügung gestellt werden. Wenn in einem Auftrag Werte für benutzerdefinierte Variablen gespeichert sind, soll über eine Markierung am Reiter darauf hingewiesen werden. Es soll möglich sein, die benutzerdefinierten Variablen auf bestimmte Abteilungen zu beschränken.

Wenn in der Mandantenkonfiguration die Einstellung "HTML E-Mail" eingeschaltet ist, gehen bei der zusammenfassenden E-Mail für wiederkehrende Rechnungen im E-Mail-Text die Zeilenumbrüche verloren.

Die zusammenfassenden E-Mails sollen korrekt als HTML formatiert sein.

Das Entfernen von Kommentaren in Beschreibungen (doppelte eckige Klammern) ist mehrmals und unterschiedlich implementiert. Z.B. werden nicht immer mehrzeilige Kommentare erkannt.

Es soll eine einzige zentrale Implementierung der Funktion geben.

Bei der Erfassung von Inventuren kommt es oft zu einem zeitlichen Abstand zwischen der tatsächlichen Zählung der Bestände und dem Einbuchen der Zählung. Lagerbewegungen, die zwischen diesen zwei Zeitpunkten gebucht werden, werden damit ignoriert und führen zu Fehlern im Lagerbestand.

Um dies zu verhindern, soll die Inventur auf einen bestimmbaren "Stichtag" durchgeführt werden können. Die entstehenden Lagerbewegungen werden zu diesem Stichtag gebucht & die angezeigten Differenzen in der Phase "Prüfung" müssen sich auf dieses Datum beziehen.

Der Stichtag wird unter "Bereich" pro Lagerort festgelegt.

Der Stichtag darf nicht mehr geändert werden, nachdem der erste Lagerplatz gebucht wurde. Erst wenn die Inventur für alle Lagerplätze eines Lagerorts beendet ist (durch Buchung oder durch inaktiv setzen unter "Bereich"), darf das Datum wieder geändert werden.

Zählungen dürfen erst gespeichert werden, sobald der Stichtag nicht mehr in der Zukunft liegt. Wenn Zählungen erfasst wurden, darf der Stichtag nicht mehr auf ein Datum in der Zukunft gesetzt werden.

Die automatische Auflösung von Über-Reservierungen (wenn eine größere Menge reserviert ist, als gezählt wurde) wird nicht unterstützt, wenn die Buchung zu einem Stichtag erfolgt, der in der Vergangenheit liegt.

Die Mengenänderung der Position in ERP-Dokumenten aktualisiert den Preis, analog zum Einfügen einer neuen Position. Diese Preisermittlung stellt sicher, dass die gewählte Preisquelle mit dazugehörigem Preis stimmt. Somit werden Preisregeln mit Mengen ab/bis oder Staffelpreise sofort im ERP-Dokument ermittelt.

1. Wenn aus Rechnungen, über den Workflow eine Gutschrift erstellt wird, ist diese Preisermittlung nicht gewünscht. Die Gutschrift soll den Preis aus der Rechnung über eine Preisquelle "Rechnungspreis" übernehmen (wie "Auftragspreis" in Rechnungen).

   Wird die Gutschrift direkt erstellt (ohne RG) ist die Preisermittlung analog zum Einfügen einer neuen Position.

Hinweis: Falls die Gutschrift (Mengen- und Preis-Gutschrift) auf eine Rechnung folgt, die eine Preisquelle mit Bedingung zur Menge enthält, kann diese Menge unterschritten werden. Somit ist der ursprüngliche Preis in der Rechnung eventuell zu niedrig und kann nachberechnet werden.

2. Anzeige der Meldung bei Preisstaffeln: "Die Rechnung enthält Positionen mit Preis oder Rabatt aus Preisregeln, die eine Bedingung zur Menge enthalten. Beachten Sie, dass durch diese Gutschrift die Menge in der Rechnung nun unterschritten sein kann."

Bei Rechnungen, welche aus mehreren Aufträgen entstanden sind, wird in der Positionstabelle eine Informationszeile ausgegeben. Diese beinhaltet die Auftrags- bzw. Lieferscheinnummer und die Vorgangsbezeichnung.

Die Logik ist im Moment in Latex umgesetzt und überprüft für jede Position die Auftragsnummer und vergleicht diese mit der nachfolgenden Position. Sind diese unterschiedlich, wird die Informationszeile ausgegeben, ansonsten nicht. Da die Basis dieser Ausgabe die Aufträge sind, kommt es regelmäßig vor, dass nicht alle Lieferscheine zu einem dazugehörigen Auftrag ausgegeben werden.

Zur Vermeidung von Fehlern soll diese Logik deshalb im Programmcode umgesetzt werden. Dabei soll die Basis der Prüfung auf Aufträge UND Lieferscheine durchgeführt werden. Ausgabe von folgenden Daten Auftragsnr., Auftragsdatum und Lieferscheinnr.

Falls in den Artikelstammdaten der Verkaufspreis, Einkaufspreis oder Listenpreis per SQL direkt in der Datenbank angepasst wird, wird automatisch ein Eintrag in der Preishistorie des Artikels mit den geänderten Werten hinzugefügt (Trigger).

Dieser Eintrag soll auch bei Änderungen von Kunden-/Lieferantenpreisen über die Datenbank erfolgen.

Buchungsgruppen von Artikeln können zur Zeit nicht geändert werden, sobald der Artikel bereits in einem ERP-Dokument verwendet wurde. Falls der Artikel in den Stammdaten mit einer fehlerhaften Buchungsgruppe erfasst wurde, ist eine einfache Korrektur nicht möglich. In den meisten Fällen ist eine Korrektur vor der Buchung der ersten Rechnung gewünscht.

Diese einfache Korrektur soll nur ermöglicht werden, wenn die "falsche" Buchungsgruppe und die "richtige" den selben Steuersatz für alle in ERP-Dokumenten verwendeten Kombinationen von Steuerzone, Land der Firmierung und Datum haben, sodass nach der Umstellung überall der selbe Steuersatz erhalten bleibt. Wenn der Artikel schon in einer Rechnung verwendet wurde, soll die Buchungsgruppe nicht mehr geändert werden können.

In Produktionsaufträgen soll die Option "Als neu verwenden" eingebaut werden. Die Option soll unterhalb des Menüpunktes "Speichern" eingefügt werden. Hierbei sollen die Positionen zwingend übernommen werden.

Wie bei Rechnungen soll angeboten werden bestimmte Felder zu Übernehmen und Verknüpfungen anzulegen:

• Verknüpfung erstellen
• Auftragsnummer und -datum übernehmen
• Produktionsstart, Versandtermin, Liefertermin übernehmen
• Formularfelder (Kunde, Abteilung, Vorgangsbezeichnung, Projekt)

Das neue Dokument soll zwar die Positionen und ausgewählten Felder aus dem alten Dokument erhalten, jedoch nicht direkt gespeichert werden.

Zur Vereinfachung der Inventuraufnahme soll es möglich sein, die Zählung mit den Lagerbeständen zum Stand des gewählten Stichtags zu befüllen. Zu diesem Zweck soll in der Maske der Zählung ein neuer Button "Aktionen" mit Menüpunkt "Lagerbestand am Stichtag übernehmen" hinzugefügt werden.

Falls bereits Einträge in der Zählung erfasst sind, sollen diese erhalten bleiben. Es sollen nur Lagerbestände übernommen werden, die noch nicht erfasst wurden. Diese Aktion soll durch einen Dialog bestätigt werden: "Es wurden bereits Bestände in der Zählung erfasst. Diese werden nicht überschrieben: Es werden nur Lagerbestände übernommen, die noch nicht erfasst wurden. Fortfahren?"

Eventuelle Negativbestände sollen auch übernommen werden. Die Buchung des Lagerplatzes soll jedoch verhindert werden, wenn die Zählung negative Mengen enthält.

Lagerbestände sollen nicht übernommen werden können, solange der Stichtag in der Zukunft liegt.

Außerdem soll eine Aktion "Zählung löschen" angeboten werden, mit der die komplette Zählung für den aktuellen Lagerplatz gelöscht werden kann. Die Aktion soll erst nach einem Bestätigungsdialog ausgeführt werden.

Um den Bericht unter "Lager/Lagerentnahme" vollständig zu gestalten, müssen Lagerbewegungen berücksichtigt werden, die über die Funktion "Inventuraufnahme" entstanden sind. Hierzu soll der von der Inventur genutzte Transfertyp angepasst werden.

Für Bestandserhöhungen soll der Transfertyp "Gefunden" genutzt werden. Für Bestandsdezimierung "Fehlbestand" In diesen Buchungen soll zusätzlich das Kommentar "Inventuraufnahme" eingetragen werden. Existierende Lagerbuchungen mit Typ "Inventur" sollen auf die neuen Typen umgestellt werden.

Um Fehler zu verhindern, sollen diese Transfertypen nicht mehr in manuellen Lagerbuchungen ausgewählt werden können.

Es soll eine Möglichkeit geschaffen werden, mit der ein Importprofil für alle Nutzer zugänglich gemacht werden kann.

Dazu soll der Nutzer in den Einstellungen und beim Erstellen des Imports die Möglichkeit haben, mittels Checkbox allen Nutzern Zugriff auf das Profil zu gewähren.

Momentan erscheint im ERP-System oftmals ein Pop-up von Google Translate, welches anbietet die Seite zu übersetzen. Dieses ist allerdings unnötig, da der User in den Einstellungen die Seiten des ERP’s übersetzen kann.

Auf den Seiten des ERP’s soll nun blockiert werden, dass sich das Google Translate Pop-up öffnet.

Falls ein Gesamtbetrag einer Rechnung mit enthalten Steuern erfasst werden soll, muss die Checkbox "Steuer im Preis inbegriffen" verwendet werden. Falls diese aktiviert/deaktiviert wird, wird das ERP-Dokument nicht neu geladen und der Gesamtbetrag nicht erneuert.

Damit der richtige Gesamtbetrag angezeigt wird, soll nach Aktivierung/Deaktivierung das ERP-Dokument neu geladen werden.

Falls eine Kundenummer bereits verwendet wird, kann ein Kunden nicht gespeichert werden. Es wird eine harte Fehlermeldung "Diese Kundennummer wird bereits verwendet." angezeigt. Das gleiche gilt auch für Lieferanten.

Diese Fehlermeldung soll als Flash-Fehlermeldung und nicht als harte Fehlermeldung angezeigt werden.

Bisher wurde beim DATEV-Export der Firmierungsname immer nur dann zum Dateinamen hinzugefügt, wenn mehr als eine Firmierung angelegt ist.

Der Firmierungsname soll auch hinzugefügt werden, wenn es nur eine einzige Firmierung gibt

Der DATEV-Export erlaubt bisher höchstens 2-stellige Steuerschlüssel. Mittlerweile gibt es bei DATEV Steuerschlüssel mit bis zu 4 Stellen. Dies soll auch beim DATEV-Export unterstützt werden.

Die Lieferinformationen sollen wie die Liefer- und Zahlungsbedingungen per Drag&Drop sortiert werden können.

Im Block "Aktion" sollen die Bezeichnungen der Listen- und Staffel-Typen zur Vereinheitlichung angepasst werden: Artikelpreisliste => Artikel-Liste Kundenpreisliste => Kunden-Liste Lieferantenpreisliste => Lieferanten-Liste Kunden/Lieferantentyp-Preisliste => Kunden-/Lieferantentyp-Liste Warengruppen-Preisliste => Warengruppen-Liste Preisstaffel => Mengen-Staffel Verrechnungseinheit-Staffel => Verrechnungseinheit-Staffel Belegdatumstaffel => Belegdatum-Staffel Lieferdatumstaffel => Lieferdatum-Staffel

Beim Verschieben von Artikeln in der Baukastenliste eines Erzeugnisses und darauffolgenden Speichern der Artikelstammdaten stehen in der Historie irreführende Einträge.

Damit für den Benutzer die Historie der Artikel besser lesbar wird, soll ein neuer Grund "verschoben" in der Historie eingebaut werden.

Es sollen folgende Ereignisse in der Historie dokumentiert werden:

• Artikel wurde entfernt, mit alter Position und Menge
• Artikel wurde hinzugefügt, mit neuer Position und Menge
• Artikel wurde verschoben, mit alter und neuer Position
• Artikel-Menge wurde geändert, mit Position, alter Menge und neuer Menge

Falls dieses Feature aktiviert wird, muss der Benutzer den Cache des Browsers leeren.

In Rechnungen (VK & EK), Debitoren-/Kreditorenbuchungen und Dialogbuchungen wird das Feld "Rechnungsnr." bzw. "Referenz" auf DATEV-konforme Sonderzeichen geprüft, falls die Konfiguration eingeschaltet ist. Wird ein nicht konformes Sonderzeichen verwendet, wird dem Benutzer eine Meldung angezeigt.

Nicht DATEV-konforme Sonderzeichen sollen auch automatisch korrigiert werden können. Dazu sollen unter "Mandantenkonfiguration"/"Einstellungen für DATEV"/"Rechnungsnummer/Referenz prüfen" folgende Auswahlmöglichkeiten angeboten werden:

• Keine Prüfung
• Nur Prüfung
• Autokorrektur

Bei Autokorrektur sollen Punkt '.' durch Schrägstrich '/' und Leerzeichen ' ' durch Minus '-' ersetzt werden. Alle anderen inkompatiblen Zeichen sollen entfernt werden.

Wenn Sonderzeichen ersetzt oder entfernt werden, soll dem Benutzer folgende Meldung am Feld angezeigt werden: "Nicht DATEV-konforme Zeichen wurden ersetzt/entfernt".

Aktuell können die 2 implementierten Reservierungs-Methoden nicht zusammen genutzt werden. Die a) Reservierungslager und die b) auftragsbezogene Bestandsreservierung zusammen erzeugen eine doppelte reservierte Menge im Artikel. a) Reservierungslager:

• Lager können als Reservierungslager konfiguriert werden
• Alle Bestände auf einem Reservierungslager gelten als reserviert b) Auftragsbezogene Bestandsreservierung:
• Im Auftrag können Bestände reserviert werden
• Für diese Bestände wird auf dem ursprünglichen Lager eine Umlagerung durchgeführt, bei der ein Verweis auf die Auftragsposition an den Bestand angehängt wird

Für jeden Artikel wird in der Datenbank der komplette und der reservierte Lagerbestand gespeichert. Dies wird gemacht, damit bei Anzeige und Prüfung der Lagerbestände diese Werte nicht jedes mal berechnet werden müssen. Verwendet werden diese Werte z.B. in den Artikelstammdaten zur Anzeige von "Auf Lager" und "Verfügbar" (= Lagerbestand - reservierter Bestand).

Der Wert für den reservierten Bestand wird immer dann aktualisiert, wenn eine Reservierung angelegt, geändert oder aufgelöst wird.

Die parallele Nutzung von beiden Methoden soll korrekt ermöglicht werden.

Außerdem wird bei Artikeln die gespeicherte Reservierungsmenge nicht aktualisiert, wenn ein Reservierungslager wieder zu einem normalen Lager wird oder umgekehrt. Die Reseriverungsmenge soll in diesem Fall bei allen Artikeln aktualisiert werden, die Bestand in diesem Lager haben.

CSV-Import-Profile können als Standardprofil markiert werden, sodass sie beim Öffnen der Maske vorausgewählt werden.

Dabei besteht zur Zeit folgender Fehler: Profile werden zwar pro Benutzer angelegt, dass Merkmal "Standardprofil" wird aber global gesetzt. D.h. wenn ein Benutzer ein Standardprofil speichert, wird das Merkmal bei allen anderen Benutzern gelöscht. Standardprofile sollen pro Benutzer gespeichert werden können.

Außerdem besteht die Möglichkeit, globale Profile zu erstellen, die für alle Nutzer verfügbar sind (Checkbox "Profil für alle Nutzer verfügbar"). Es soll ermöglicht werden, ein globales Profil als Standardprofil zu markieren. Beim Öffnen der Maske soll das globale Standardprofil ausgewählt werden, außer der Benutzer hat ein eigenes Profil als Standard festgelegt.

Die Checkbox "Zu Standardprofil machen" soll umbenannt werden zu "Standardprofil". Wenn ein Profil geladen wird, soll die Checkbox entsprechend der gespeicherten Einstellung gesetzt werden.

Durch das letzte Update werden beim Ausdruck Mengenangaben immer fest mit der konfigurierten Anzahl von Nachkommastellen für Mengen ausgegeben. Bei Mengen sollen wieder nur so viele Nachkommastellen wie nötig im Ausdruck angezeigt werden.

Beim Massendruck von Materiallisten wird folgende Fehlermeldung angezeigt: Can't call method "company" on an undefined value at /opt/erp/mbb/prod/odyn-erp/SL/Form.pm line 3653.

Das Massendrucken von Materiallisten soll ohne Fehler funktionieren.

Die Option "In Rechnung gestellt" im Suchformular zu Aufträgen erzeugt im Bericht die zwei Spalten "Abgerechneter Betrag" und "Offener Betrag". In diesen werden NUR Rechnungen berücksichtigt, die über einen Lieferschein erstellt wurden. Das führt zu falsche Werten im Bericht.

Es sollen immer alle Rechnungen (direkt erstellte oder über "Workflow") berücksichtigt werden, analog zu der Option "Abzurechnende Summe".

Info: Wenn die Steuerzone keine Steuer hat ist Betrag=Summe, sonst sind die Werte in "Betrag" OHNE und die "Summe" MIT Steuer.

Das Info-Icon mit Tooltip neben der Preisquelle gibt weitere Informationen an den Benutzer. Zum Beispiel wird darüber informiert, dass ein Rabatt aufgrund einer Preisregel nun höher wäre.

Das Ausrufezeichen-Icon informiert, dass eine bessere Preisquelle als die ausgewählte vorhanden ist. Bei gleichen Rabattwerten ist die Anzeige fehlerhaft und indiziert einen besseren Rabatt obwohl keiner verfügbar ist. Falls ein besserer Rabatt oder Preis verfügbar ist, wird dies über ein Info-Icon und Tooltip neben dem Preisquellen-Button in der Position vermerkt.

Es soll immer nur über bessere Rabatte informiert werden wenn diese auch einen anderen Wert haben.

Der Einkaufspreis variiert zwischen den Artikelstammdaten und dem Artikelbericht. Es soll analysiert werden, wie es dazu kommt und anschließend behoben wird.

Es soll immer der EK-Preis aus dem editierbaren Feld der Stammdaten angezeigt werden. Wenn die Option "Errechenter EK-Preis" aktiv ist, soll zusätzlich der EK-Preis aus der gesamten Stückliste (wie in der Baukastenliste) bestimmt und angezeigt werden.

Zusätzlich soll die Suchoption "Errechneter EK-Preis" mit einem Info-Popup versehen werden, welches ihre Funktion erläutert. Die Spalte mit den Werten "Errechneter EK-Preis" soll als vorletzte Spalte ausgegeben werden. Als letzte Spalte soll eine neue Spalte "Errechnet Gesamt" ausgegeben werden.

Beim Erfassen von Preisregeln werden die Kontrollelemente zum Hinzufügen von Blöcke in (Unter-)Bahnen erst angezeigt, wenn im Block ein Typ ausgewählt wird. Wenn ein neuer Bedingungsblock in der selben Bahn hinzugefügt wird, zeigt der Pfeil zwar nach rechts, der neue Bock erscheint aber links des Pfeils, da die Kontrollelemente links des Blocks erst hinzugefügt werden, wenn eine Bedingung ausgewählt wird.

Die Kontrollelemente vor einem Block sollen auch angezeigt werden, wenn noch kein Typ gewählt wurde.

Außerdem kann es passieren, dass Blöcke in die selbe Bahn, statt in eine neue Unterbahn hinzugefügt werden: Dadurch erscheint zwischen den Bedingungsblöcken ein Aktionsblock, der nicht mehr gelöscht werden kann.

Die Blöcke sollen immer korrekt in die Bahn oder Unterbahn eingefügt werden.

Um eine Nachkalkulation von Projekten zu gewährleisten, werden in den Stammdaten von Projekten im Reitern "Projekt Details" Daten aus Aufträgen angezeigt und zusammengefasst. Bei den Berechnungen und Anzeigen werden fälschlicherweise Angebote berücksichtigt.

In den Projektstammdaten sollen nur Daten aus Aufträgen berücksichtigt werden.

In Kreditorenbuchungen werden die FiBu-Konten für Zahlungseingänge mit Kontonummer und Kontobeschreibung angezeigt.

Sobald der Zahlungseingang jedoch nicht mehr änderbar ist fehlt die Beschreibung des Kontos und es ist nur noch die Nummer sichtbar.

Es soll immer die vollständige Kontobezeichnung im folgenden Format angezeigt werden: [Kontonummer]--[Kontobeschreibung]

In der letzten Zeile des Verkaufsberichts wird die Summe der Spalte angezeigt. Die Summe für die Spalte Gewicht wird jedoch immer als 0 Angezeigt.

Die Summe des Gewichts soll korrekt berechnet und angezeigt werden.

Wenn für einen Auftrag wiederkehrende Rechnungen aktiv sind, werden mit der angegebenen Periodizität wiederholt Rechnungen erstellt. Solange wiederkehrende Rechnungen erstellt werden, soll der Auftrag offen bleiben. D.h. in diesem Fall wird der Auftrag nicht geschlossen, wenn alle Positionen mit vollständiger Menge abgerechnet sind, wie es bei manueller Rechnungserstellung der Fall wäre.

Die Prüfung auf aktive wiederkehrende Rechnung ist jedoch fehlerhaft: Es wird nur geprüft ob eine Konfiguration für wiederkehrende Rechnungen existiert und nicht ob diese auch aktiviert ist. Wenn man die Konfiguration für wiederkehrenden Rechnungen speichert, ohne sie aktiv zu setzen, sorgt dies dafür, dass bei manueller Rechnungserstellung der Auftrag nicht geschlossen wird.

Beim Buchen von Rechnungen soll korrekt geprüft werden ob die Konfiguration für wiederkehrenden Rechnung im Auftrag aktiv ist.

Vom Kunden "10848 EDEKA Foodservice Stiftung & Co.KG GM Schorndorf" werden per EDI Bestellungen mit 2 unterschiedlichen GLN-Nummern gesendet.

GLN 4314123597054 EFS GM Schorndorf - Ist die aktuelle GLN des Kunden GLN 4314123586102 EFS Schorndorf GV - Ist die alternative GLN. Ist aktuell nicht im ERP hinterlegt

Diese Bestellungen können aufgrund der unterschiedlichen GLNs nicht dem gleichen Kunden zugeordnet werden. Aktuell wird entweder die GLN im Kundenstamm oder die GLN Nummer in der EDI-Datei geändert.

Beim EDI-Import soll der Kunde auch über die GLNs in Lieferadressen gefunden werden. Somit können die alternativen GLNs als Lieferadressen angelegt werden.

Um eine Nachkalkulation von Projekten zu gewährleisten, werden in den Stammdaten von Projekten in den Reitern "Projekt Details" und "Auftragsdaten" Daten aus Aufträgen angezeigt und zusammengefasst. Bei den Berechnungen und Anzeigen werden fälschlicherweise Angebote berücksichtigt.

In den Projektstammdaten sollen nur Daten aus Aufträgen berücksichtigt werden.

Soll ein Artikel "ungültig" gesetzt werden, so wird beim Speichern der Artikelstammdaten auf Bestand geprüft. Ist noch Bestand des ausgewählten Artikels vorhanden, kann der Artikel nicht als "ungültig" markiert werden. Die durchgeführte Bestandsprüfung beim Setzen der Markierung "ungültig" zeigt Bestände an, die nicht im Lager sind.

Die Prüfung auf Bestand bei Markierung als "ungültig" soll korrigiert werden.

Dieses Prüfungsergebnis wird aufgrund von Beständen mit MHD erreicht. Diese Bestände sind für den Kunden unsichtbar, da das MHD sonst nicht verwendet wird. Es sollen die vorhandenen Bestände korrigiert werden und das MHD aus den Lagerbuchungen entfernt werden, die Prüfung verläuft korrekt.

Im Lager gibt es negative Reservierungsbestände, die durch Freigabe von nicht reservierten Beständen entstanden sind.

Es soll verhindert werden, dass Freigaben für nicht reservierte Bestände entstehen. Die falschen Bestände sollen bereinigt werden.