08.02.2024

Aktuell wird für Retoure-Lieferscheine im Verkauf ein separater Nummernkreis geführt.
Auf Kundenwunsch soll dieser in der Mandantenkonfiguration wie folgt konfigurierbar sein:
a) separater Nummernkreis (wie aktuell)
b) Präfix Retoure "RL" mit Ziffern vom Verkaufs-Lieferschein
c) weitere Retouren zum selben Verkaufs-Lieferschein haben ein Suffix "_X" wobei X die höchste Suffix-Zahl +1 ist.
    Also erster Retouren-Lieferschein: RL1111, zweiter RL1111_1, dritter RL1111_2 etc.
d) Ist eine Retouren-Lieferschein-Nr. bereits vorhanden, wird auch ein Suffix +1 angehängt

Beispiel: VL10000 → RL10000, VL12345 → RL12345, 2 Retour für VL99999 → RL99999_1

Werden in der Positionstabelle von ERP-Dokumenten zusätzliche Informationen (Langtext, Artikeldetails, Stammdaten, …) einer Position geöffnet und wieder geschlossen, kann der Benutzer danach nicht mehr erkennen in welcher Position er gerade war. Gerade bei ERP-Dokumenten mit mehreren Positionen (>10) ist es wichtig den Focus von der Position nicht zu verlieren.

Nachdem für eine Position zusätzliche Informationen wie Langtext, Artikeldetails oder Stammdaten geöffnet werden soll die aktuelle Zeile markiert werden. Dabei soll der Fokus auf Feld "Nummer", "Beschreibung" oder "Menge" (je nach Benutzereinstellung) stehen.

Um auf wiederkehrende Aufgaben im ERP-System aufmerksam zu machen, sollen im ERP-System periodische Wiedervorlagen erstellt werden können. Eine Wiedervorlage kann als "monatlich" oder "jährlich" markiert werden. Ist eine Wiedervorlage als periodisch markiert, wird beim Schließen dieser Wiedervorlage eine neue Wiedervorlage mit gleichem Inhalt und angepassten Datum (Wiedervorlage Datum + 1 Monat/Jahr) erstellt.

Auftrag mit "wiederkehrende Rechnungen" aktiv, übergeben immer auch den Langtext an die Rechnung. Wenn dieser Langtext im Auftrag benötigt wird, aber nicht in der Rechnung, muss nach der Auftragsbestätigung der Auftrag angepasst werden. Die Konfiguration zu "wiederkehrende Rechnungen" soll eine neue Einstellung erhalten: "Artikellangtexte bei Rechnungserstellung entfernen".

So ist nach Auftragsbestätigung eine Anpassung für die wiederkehrenden Rechnungen nicht erforderlich.

Zur Zeit werden Übersetzungen für das ERP aus einer großen Übersetzungsdatei (pro Sprache) geladen. Alle Übersetzungen müssen dort hinterlegt werden, damit verschiedene Sprachen korrekt funktionieren.

Mit der Einführung von Erweiterungen ist nun die Problematik aufgetreten, das Übersetzungen die nicht immer im ERP vorhanden sind, z.B. DHL-Erweiterung, unnötigerweise Einträge in den Übersetzungsdateien erzeugt. Zusätzlich treten immer wieder kundenspezifische Umbenennungen auf, z.B. delivery_order nicht mit "Lieferschein" sondern "Leistungsnachweis" übersetzen.

1. Das Anlegen von Übersetzungen nur für Erweiterungen wird implementiert.
2. Über die Angabe einer Reihenfolge können zukünftig Übersetzungen überschreiben werden, um auch kundenspezifische Umbenennungen als "Übersetzungs-Erweiterung" zu Implementieren.

In Lieferscheinen kann derzeit eine Charge in einem Freitext-Feld eingetragen werden. Wenn für diese Position eine Lagerzuweisung erfolgt, wird eine zuvor eingetragene Charge überschrieben und durch Chargen (mit Leerzeichen getrennt) der Lagerzuweisung ersetzt. Es ist jedoch möglich, die Charge vor dem nächsten Speichern erneut zu überschreiben.

Dieses Verhalten ist zu komplex und die Quelle der Charge ist nicht ersichtlich, daher werden folgende Punkte implementiert:
1. Wurde eine Charge eingetragen, kann mit dem '?'-Button eine Lagerzuweisung nicht erfolgen.
    Eine Warnung zeigt an, dass die eingetragene Charge entfernt werden muss, für eine Lagerzuweisung.

2. Erfolgte eine Lagerzuweisung, wird das Freitext-Feld zu einem schreibgeschützten Feld und die Chargen angezeigt.

3. Abhängig von der Druckvorlage und Konfiguration:
    a) werden pro Position mehrere Chargen mit Leerzeichen getrennt ausgegeben
    b) wird die Menge pro Charge ausgegeben z. B.: „2 kg Charge 7411 (MHD 01.02.2024)“

Retouren-Lieferscheine sollen auch in den Einkauf implementiert werden. Folgende Funktionen werden implementiert:

• Direktes Erstellen von Retouren-Lieferscheinen aus der EK-Auftragssuchmaske (ohne existierendes Dokument)
• Erstellen von Retouren-Lieferscheinen aus einem EK-Auftrag über Workflow
• Auslagern und Stornieren der Auslagerung über Retouren-Lieferscheine
• Erstellen von EK-Rechnungen aus Retouren-Lieferscheinen. Diese Rechnungen haben eine negative Menge.

Mit dem Ticket #19560 wurde ein neues Verhalten zum Zerlegen von Erzeugnissen im Einkauf implementiert. Für dieses Verhalten, wurde eine Funktion implementiert, welche auch in einem anderen Kontext verwendet werden könnte. Um sicherzustellen, dass die Funktionalität für Einkaufslieferscheine auch in Zukunft bestehen bleibt, sollen Tests entwickelt werden, welche den "Use Case" des Einkaufslieferscheins darstellen.

Nicht mehr genutzte Lagerplätze können aus den Auswahlfeldern in den Lagern nicht entfernt werden. Damit die Benutzer nicht aus Versehen auf ein nicht mehr genutzten Lagerplatz buchen soll es möglich sein Lagerplätze, welche keinen Bestand haben auf ungültig zu setzen.

Mit dem Ticket #20115 Versandeinheitenrabatt wurde eine neue Art von Bedingung für Preisregeln, sowie eine neue Art Rabatt implementiert:

• Bedingung: Menge im Dokument ist restlos durch die Versandeinheit des Artikels teilbar. Die Versandeinheit (auch „Colli“ genannt) ist die Menge von einzelnen Artikeln die für den Versandt zusammengefast werden.
• Mehrere Rabattquellen Speichern können In der Mandantenkonfiguration unter Rabattquellen ist eine Mehrfachauswahl nun möglich.
• Neues Merkmal für Preisregeln "Zusatzrabatt" um "Zusammengefasste Rabatte" zu erhalten Dieses neue Verhalten soll nur verwendet werden wenn "Zusammengefasste Rabatte" in der Mandantenkonfig aktiv ist

Diese Feature werden nun in den Standard von odyn-erp übernommen.

Die "Massenerstellung von VK-Rechnungen" und das Drucken aus dem "Suchbericht zu VK-Rechnungen" fasst mehrere Rechnungen in ein PDF-Dokument zusammen.

Um pro VK-Rechnung (ERP-Dokument) ein PDF-Dokument zu erhalten, wird das "Drucken" mit der Option "Zip-Archiv Erstellen" implementiert:

1. Unter "Massenerstellung von Rechnungen aus Lieferscheinen" zum Berichte "Erzeugte Rechnungen"
2. Und im Suchbericht zu VK-Rechnungen

Für den Emailversand aus dem ERP, als Email-Versandadresse, wird Standardmäßig das Postfach des Benutzers genutzt.

Um Verkaufs-Rechnungen und Verkaufs-Gutschriften von einer "festen" Versandadresse (nicht die des Benutzers) zu versenden, soll unter System/Stammdaten/Firmierungen das Feld "Email-Versandadresse für VK-Rechnungen/-Gutschriften" genutzt werden.

Die zwei Feld-Beschreibung wie folgt ändern: Email-Versandadresse für Verkaufs Rechnungen/Gutschriften wiederkehrende Rechnung

Beim Speichern von Preisregeln soll eine Prüfung auf Überschneidungen durchgeführt werden. Das sind „zusammenhängende“ Teilmenge oder Untermengen die nicht exakt gleich sind, sich aber überschneiden. Insbesondere bei Menge, Datum etc, wie z. B.: Eine Preisregel behandelt die Menge < 10 und eine weitere behandelt die Menge > 8, dies führt zur Überschneidung in der Menge 9.

In diesen Fällen soll eine Warnung angezeigt werden.

In den Stammdaten der Kunden kann nach Rechnungs-/Lieferadresse gefiltert werden. Im Suchbericht wird jedoch nur die Rechnungsadresse angezeigt.

1. Da es einen separaten Bericht für die Lieferadressen gibt, soll die Suche nach Lieferadressen entfernt werden.
2. Im Lieferadressen-Bericht ist die Filtereinstellung "Aktiv" unklar benannt. Es handelt sich hier um verwendete Lieferadressen. Der Filter wird in "verwendet" umbenannt.
3. Der Menüpunkt wird nach oben, unter Ansprechpersonen, verschoben.

Um bei wiederkehrenden Rechnungen die richtige Periode zu definieren, ist es möglich in den Aufträgen Variablen zu verwenden. (z. Bsp.: "<%currentmonthlong%>", "<%current_year%>"). Diese werden dann beim Erstellen der Rechnung durch die jeweiligen Daten ersetzt.

Für wiederkehrende Rechnungen sollen eigene Vorgangsbezeichnung in der Konfiguration angegeben werden können, damit die Vorgangsbezeichnung für die Rechnungen nicht im Auftrag definiert werden muss. Falls diese fehlt, wird die Vorgangsbezeichnung des Auftrags verwendet.

Wenn in der Mandantenkonifguration unter Lager/Mindesthaltbarkeit anzeigen die Einstellung geändert wird obwohl noch Bestände mit MHD vorliegen, kann es zu Problemen kommen. Bestände existieren noch, werden aber unter Umständen für den Benutzer unsichtbar. Das führt ebenfalls zu Problemen mit einigen internen Funktionen.

Es soll nicht mehr möglich sein, die Einstellung zu ändern so lange noch Bestände mit MHD vorliegen. Diese müssen zunächst genullt werden.

Es soll eine Prüfung eingebaut werden welche den Wechsel überprüft und nur zulässt wenn keine Bestände vorliegen. Falls nicht soll eine Fehlermeldung angezeigt werden: "Der Wechsel der Einstellung ist nur möglich wenn keine Bestände mit MHD mehr vorliegen"

Unter "Mandantenkonfiguration/Features/Zahlungen pro Empfänger gruppieren" kann eingestellt werden, dass SEPA-Anweisungen zusammengefasst werden können. Durch diese Einstellung ist es dem Benutzer möglich, weniger Einzelüberweisungen für einen Kunden/Lieferanten erzeugt werden.

Diese führt im Verkauf, bei der Erstellung von Bankeinzügen, auch zu einer falschen Gruppierung die nicht passieren sollte. Um diese Fehler zu vermeiden soll die Gruppierung nur für den Einkauf ausgeführt werden.

Zusätzlich ist es bei einigen Banking-Anwendungen nötig SEPA-Anweisungen als XML-Dateien zu importieren. Es soll eine Mandantenkonfig erstellt werden, welche SEPA-Lastschriften als auch SEPA-Überweisungen als XML-Datei statt cct/cdd exportiert.

Unter "https://wiki.opendynamic.de/books/odyn-erp/page/rahmen-und-abrufauftrage" wurde eine Anleitung zu Rahmen - und Abrufaufträgen erstellt.

Dieser Artikel soll im ERP-System in Rahmen- und Abrufaufträgen aufgerufen werden können.

Große Beträge können mit der Rundungs-/Formatierungsfunktion "sprnitf" zu Fehlern in den Nachkommastellen führen.

Eine Zahl mit zwei Stellen vor dem Komma und einer danach (16.3. kann ohne weiteres auf 12 Nachkommastellen formatiert werden. Sobald diese Zahl jedoch betragsmäßig größer wird, schleichen sich Fehler ein, z.B. wird aus 19700.8 auf 12 Nachkommastellen nicht 19700.800000000000 sondern 19700.799999999999, was zu Fehlern in der Darstellung führt.

Es soll überdacht werden wie die Funktion zur Darstellung von Zahlen vorgeht um diese Fehler zu vermeiden. Der Fehler kann gut mitigiert werden indem die Anzahl der Nachkommastellen reduziert wird. Allgemein auf 12 Nachkommastellen zu runden ist nicht immer sinnvoll, da die Datenbank Zahlen auch nur mit einer Genauigkeit von 5 Stellen speichern kann.

Wenn kein Preisfaktor gewählt wird, ist das z.Z. gleichbedeutend mit Preisfaktor "1 zu 1". Wenn nun ein abweichender Preisfaktor aus Versehen entfernt wird, entsteht ein Fehler: Das System kann zwischen "Wert fehlt" und "Preisfaktor "1 zu 1 " nicht unterscheiden.

Es sollen folgende Änderungen vorgenommen werden:

• Ein leerer Preisfaktor soll intern als "1 zu 1" gelten und standardmäßig angelegt werden (leere Beschreibung und Faktor 1.
• Der Preisfaktor soll ein Pflichtfeld werden. Falls kein Preisfaktor gesetzt wird, kann ein Artikel nicht gespeichert werden.
• Die Preisfaktoren-Auswahl soll keine leere Auswahl mehr zulassen

Obwohl die Einstellung "Formulardetails" auf "Standardmäßig verstecken" gesetzt ist, muss bei neu angelegten Benutzern immer zuerst die Benutzereinstellung gespeichert werden, sodass diese Einstellung greift.

Bei neuen Benutzern sollen die Benutzereinstellungen so verwendet werden, wie sie auch eingestellt sind.

Aktuell gibt es keinen Hinweis das unter dem Reiter "Vorschläge" auch die Beträge übereinstimmen müssen. Daher soll ein Satz im Hilfe-Text wie folgt erweitert werden: "Hat eine Rechnung über 13 Punkte (grün) und ihr Betrag oder ihr offener Betrag ist gleich dem Betrag der Kontobewegung, so wird diese im Reiter "Vorschläge" der Kontobewegung angezeigt. …

Background Jobs werden oft mit Zusatzdaten angelegt. Dabei sind oft Dateipfade, E-Mailadressen oder Start- und Enddatum enthalten. Wenn die Daten nicht korrekt geparst werden können, schlägt der BackgroundJob fehl und sperrt den Taskserver in eine ewige Schleife von Fehlversuchen. Dadurch können keine weiteren BackgroundJobs mehr gestartet werden.

Um dieses Problem zu verhindern, solle folgendes umgesetzt werden:

• Die Funktion zum parsen der Job-Daten soll mit einer Prüfung versehen werden. Wenn nicht korrekt geparst werden konnte, soll der Job abbrechen und eine Fehlermeldung in der History hinterlegen.
• Es soll ein Wiki-Eintrag erstellt werden, der das korrekte Datenformat erklärt.

1. Momentan ist es nicht möglich, einen Rahmenauftrag zu erstellen, ohne einen dazugehörigen Abrufauftrag anzulegen. Es soll ermöglicht werden, dass Aufträge, unabhängig von der Existenz eines Abrufauftrags, in Rahmenaufträge umgewandelt werden können.

2. Im Dropdown_Menüs des Workflows in Aufträgen soll die Option "Abrufauftrag" in "Rahmenauftrag" umbenannt werden.

3. Die Pop-up Meldung, die angezeigt wird, wenn über den Workflow in einen Rahmenauftrag umgewandelt wird, soll wie folgt angepasst werden: "Dieser Auftrag wird als Rahmenauftrag in der Datenbank gekennzeichnet. Wollen Sie fortfahren?"

Der Lagerbestand kann zu einem Stichtag (Lagerbestand am:) anzeigen werden. Dabei wird der Bestand zum Stichtag mit aktuellem EK-Preis und dem daraus folgendem Bestandswert angezeigt.

Zukünftig soll bei Verwendung vom Stichtag auch der EK-Preis aus der Historie des Artikels genommen werden. Ohne Stichtag wird der aktuelle EK-Preis aus den Stammdaten genommen.

Benutzerdefinierte Datenexporte werden in zwei Menüs geführt: Unter Berichte/ und System/Benutzerdefinierter Datenexport Die beiden Orte dienen grundsätzlich unterschiedlichen Zwecken. Unter Berichte soll der BDE ausgeführt werden, unter System können BDEs angepasst, erstellt und gelöscht werden.

1. Die Überschriften der Menüs sollen überarbeitet werden: Unter Berichte soll "Benutzerdefinierter Datenexport" als Überschrift vorhanden sein. Unter System soll "Benutzerdefinierter Datenexport - Erstellen/Anpassen" stehen.
2. Es ist möglich eine mehrzeilig formatierte Beschreibung für BDEs zu erfassen, diese werden in der Übersicht ohne Formatierung angezeigt und als Link dargestellt. Die Anzeige als Link soll entfernt werden und die Formatierung erhalten bleiben.

Es soll eine neue Rabattquelle implementiert werden: "Kein Rabatt". Wenn die Preisquelle "Preisregel" aktiv ist und keine Rabattquelle gefunden wird, soll "Kein Rabatt" als Rabattquelle ausgewählt werden. Die Rabattquelle soll keinen Wert bei Rabatt angeben und nicht editierbar sein.

Benutzer können für Rabattquelle "Freier Rabatt" auswählen, um einen Wert für Rabatt eingeben zu können. Außerdem ist der Stammdaten-Verkaufspreis gleich editierbar. Dieses Verhalten soll auf das Standard-Verhalten zurückgestellt werden. Dabei ist der Verkaufspreis nur editierbar, wenn die Preisquelle "Freier Preis" ist.

Die Preise und Rabatte in odyn-ERP werden über Preisquellen und deren Punkte für die Priorität bestimmt. Bei dem Einfügen einer Position entscheidet die Preisquelle mit der höchsten Priorität und dem niedrigsten Preis bzw. dem höchsten Rabatt.

Die Priorität der Preisquellen ist zur Zeit den Benutzern nicht ersichtlich. In dem Pop-Up zu Preisquellen soll nun die Priorität angezeigt werden.

Die aktuelle Warnung zu Kunden- / Lieferanten-Wechsel hat zu viel Text und kann leicht ignoriert werden:

✘Warnung Kundenwechsel/Lieferantenwechsel haben Einfluss auf den Preis der Position. (Mögliche Einflüsse: Kunden/Lieferanten-Preise, Preisregeln, Rabatt oder "Freier Preis") Überprüfen Sie diesen oder aktualisieren Sie den Preis über "Artikel aktualisieren".

Lösung/Aufgabe:

1. Erzwungener Dialog mit weniger Text: Nach einem Kunden-/Lieferanten- Wechsel können Artikel nicht aktuell sein.
   Sollen die Artikel aktualisiert werden? Ja / Nein
   

2. Bei 'Ja' das Popup "Artikel aktualisieren" anzeigen

In odyn-ERP werden Aufträge und Lieferscheine geschlossen, wenn sie vollständig in Rechnung gestellt sind.

Es sollen automatische Tests angelegt werden die sicherstellen das dieser kritische Prozess ordnungsgemäß funktioniert.

Für automatische Tests und die Bereitstellung über eine Schnittstelle ist es vorteilhaft Funktionen/Methoden über das ORM Rose bereitzustellen das odyn-ERP bereits verwendet.

So können Aufträge, Rechnungen, etc. mit einem Aufruf aus der Datenbank geladen werden und oft benötigte Funktionen ebenfalls mit nur einem Aufruf durchgeführt werden, z.B. das Umwandeln eines Auftrags zu einem Lieferschein.

VK-Rechnungen haben bereits eine "post" Methode, die das Buchen über Rose ermöglicht. EK-Rechnungen sollen nun eine äquivalente Methode erhalten.

Diese Methoden werden unter anderem bei den automatischen Tests verwendet, um die korrekte Funktionsweise von odyn zu gewährleisten.

Wenn im Bericht der Lieferantenaufträgen der Filter "In Rechnung gestellt" ausgewählt wird, wird die Spalte "Offener Betrag" angezeigt. In dieser Spalte werden falsche Werte angezeigt. Außerdem wird in der Spalte "Lieferschein erstellt" "Nein" angezeigt, obwohl aus Lieferantenaufträgen Lieferscheine mit der gesamten Menge angezeigt werden.

Es muss herausgefunden werden, warum die Werte falsch sind und das Problem korrigiert werden.

Benutzerdefinierter Datenexport »Artikelstamm für Kundengruppen« mit Wert "7040%" ausführen. Schon in der Vorschau sind die Zeilen mit "Lieferanten Artikel Nummer" 71539 und 70170 überflüssig.

Bitte um Analyse wieso in der "Erweiterte Suche der Preisregeln" beide Artikel nicht ungültige Mikro Preisregeln haben? Es konnte keine gültige Makro-Preisregel zu diesen Micro-Preisregeln gefunden werden!

Grund: Die Makro-Preisregel zu denen die Mikro-Preisregel gehört haben wurde gelöscht. Es existiert ein BackgroundJob der ungültige Preisregeln entfernt sofern sie nicht in ERP-Dokumenten verwendet werden. Leider wird dafür die Verknüpfung zur Makro-Preisregel benötigt, die ja aber gelöscht ist.

Lösung: Mikro-Preisregeln die keine Makro-Preisregeln mehr haben, werden ebenfalls vom Taskserver gelöscht.

Wenn große Rechnungen (min. 100 Positionen) aus dem Lieferschein-Bericht erstellt werden, kann es vorkommen das eine Fehlermeldung erscheint. Diese verhindert das Speichern der Rechnung.

Das Speichern von Rechnungen dieser Art soll immer fehlerfrei möglich sein.

Zusätzlich soll die Fehlermeldung die bei einem "Deadlock" angezeigt wird angepasst werden, so das klar ist das die Aktion wiederholt werden kann.

Beim Berechnung des Rabattes wird der Rabattbetrag mit mehr als zwei Nachkommastellen verwendet. Dadurch kann es bei der Berechnung des Gesamtbetrages zu einem Ergebnis mit Millicents und einer falschen Rundung kommen.

Um das Problem an der Wurzel zu beheben, soll der Rabattbetrag kaufmännisch auf zwei Nachkommastellen gerundet und für die Berechnung des Gesamtbetrages verwendet werden.

Wenn ein Lieferschein mit einer temporären Lieferadresse an die DHL-Schnittstelle exportiert wird, tritt ein Fehler auf. Dies liegt am Land, in der temporären Lieferadresse, das ein Freitextfeld ist.

1. Es soll wie in den Stammdaten ein Picker für das Land eingebaut werden.
2. Um Probleme mit bestehenden ERP-Dokumenten zu vermeiden, soll ein SQL-Skript zur Konvertierung des Landes erstellt werden.

Der Produktionsauftrag "00007301" kann nicht rückgemeldet werden, es kommt folgende Meldung: "Nicht genug im Lager zum Reservieren: Kann keine 120 kg von 957161 Rezeptur: Aqua Release 470 conc. belegen, es fehlen 60 kg"

Ursache: Zu den verknüpften Angebotspositionen wurde versucht auch eine Reservierung zu erstellen. Dies wird nun auf Auftragspositionen eingeschränkt.

Standardmäßig wird aus dem Verkauf ein Einkauf ausgelöst, z. B.: VK-Angebot löst eine EK-Anfrage (EK-Angebot) aus oder ein VK-Auftrag löst ein Lieferantenauftrag (EK-Auftrag) aus.

In bestimmten Fällen ist eine Ausnahme sinnvoll:
Z. B. Der VK-Auftrag ist die Reparatur zur einer Maschine. Genauer betrachtet ist der Auftrag erst eine Analyse und ein weiterer die Reparatur. Denn erst nach der Analyse ist das erforderliche Material oder der Aufwand ersichtlich und eine Freigabe dazu kann erfolgen. In der Praxis werden diese zwei Aufträge gerne als ein Auftrag gesehen und behandelt.

Um diesen Prozess zu unterstützen, sollen EK-Artikel in einen verknüpften VK-Auftrag übernommen werden können.
Dafür ist im EK-Auftrag die neue Aktion "Positionen zu Verkaufsauftrag kopieren".

Es kommt immer wieder vor, dass fehlerhafte Aufträge oder bereits stornierte Aufträge im SAP-Import Ordner abgelegt wurden. Diese Aufträge können nicht über das ERP entfernt werden. Dadurch entsteht regelmäßig Verzögerung in der Bearbeitung, da erst der Support kontaktiert werden muss, sowie Aufwand und Belastung des Support. Den Benutzern soll es möglich sein, fehlerhafte oder falsche Aufträge aus dem SAP-Import-Ordner zu löschen.

Dafür soll ein neues Recht "Löschen von SAP-Import-Dateien" angelegt werden. Benutzern mit diesem Recht soll in der Importmaske unter "mehr…" eine neue Aktion "Löschen von Importdateien" angeboten werden. Bei Aufruf der neuen Funktion soll ein Pop-Up erscheinen, in dem die vorliegenden Dateien mit Checkboxen versehen und gelöscht werden können.

Kunde-Stammdaten haben Benutzerdefinierte Variable "Ohne Aufschlag". Grundsätzlich ist in Rechnungen der Export ausgegraut/nicht wählbar wenn kein Artikel "Teuerungszuschlag" in der Positionstabelle vorhanden. Ausnahme sind Kunden mit gesetzter BDV "Ohne Aufschlag".

1. Diese Funktion kann aus dem Code entfernt werden
2. Diese BDV kann gelöscht werden

Unter Produktion/Rückmeldung von Ansätzen erfolgt die Rückmeldung von Produktionsaufträgen (PA) und Abfüllanweisungen (AA). In der Rückmeldung von PAs kann die Qualitätsprüfung übersprungen werden, durch Checkbox "Überspringe Qualitätskontrolle" und ein Kommentar steht dann frei zur Eingabe.

Unter Produktion/Rückmeldedaten mit Datenbasis "PA-Qualität" werden durchgeführten Qualitätsprüfungen angezeigt.

1. Zukünftig sollen auch eine "Übersprungene Qualitätskontrolle" angezeigt werden. In der Spalte Merkmal als "Übersprungene Qualitätskontrolle" und eine weitere Spalte mit dem dazugehörigen Kommentar
2. Rückmeldedatum soll auch angezeigt werden (wie bei Datenbasis PA-Menge)

Das Einkaufsgebinde kann auch zum Einheit-Wechsel benutzt werden. Bedeutet, dass eine Einheit vom Einkaufsgebinde geliefert, aber eine andere eingelagert wird. Z. B.: Es wird ein IBC von 300 L eingekauft und dessen Bestandteil soll in kg eingelagert werden. Einheit vom Einkaufsgebinde ist IBC und der erste Bestandteil hat Einheit kg mit Menge 300. Der errechnete EK-Preis ist 1,00 EUR mit Einheit IBC und ist falsch. Richtig wäre 1,00 EUR pro kg.

Deshalb soll im Einkaufsgebinde der errechnete EK-Preis (in Klammern) mit der Einheit vom ersten Bestandteil angezeigt werden.

Durch einen Prozess im ERP werden Produktionsaufträge (ohne Historie) erzeugt, die keine Firmierung, Positionen oder Verknüpfungen haben. Der Status der PAs ist "Produziert"=Nein, "Geschlossen"=Ja, "Produktionsstatus"=geplant. Vermutet wird eine Kombination von Workflow und spezieller Handhabung vom User führt zu diesen leeren PAs.

Da nicht alle Prozesse identifiziert werden konnten wird ein BackgroundJob implementiert, der diese PAs periodisch entfernt.

Unter Umständen kann es vorkommen, dass Artikel, welche in der Materialliste enthalten sind, bei der Produktion nicht verwendet worden sind. Diese Artikel werden vom Produktionslager wieder zurückgegeben.

Um diesen Workflow abzubilden, soll es möglich sein, in den Materiallisten eine umgekehrte Umlagerung durchführen zu können. Dazu sollen 2 neue Features implementiert werden:

1. Artikel Zurücknehmen
   • Unter „mehr“ soll die neue Funktion „Artikel Zurücknehmen“ in die Action-Bar hinzugefügt werden. Es soll möglich seinen, einen Artikel zu wählen und danach diese Funktion aufzurufen. Es soll ein Modal erscheinen, in welchem die neue Menge für diese Position gewählt werden kann.
   • Wird die Menge auf 0 geändert, soll der Artikel entfernt werden.
   • Nach dem Verwenden der Funktion soll ein History Eintrag erstellt werden.
   • Wenn die Position umgelagert ist, dann muss eine Gegenbuchung gemacht werden mit einer Umlagerung. Ist die Materialliste bereits produziert, dann muss mit einer Gegenbuchung neuer Bestand eingelagert werden.
   • Wurde die Materialliste bereits produziert, muss daraufhin ebenfalls das jeweilige Erzeugnis angepasst werden.
2. Artikel Tauschen
   • Unter „mehr“ soll die neue Funktion „Artikel Tauschen“ in die Action-Bar hinzugefügt werden. Nach dem Wählen eines Artikels und einer Funktion soll ein Modal geöffnet werden. In diesem Modal soll es möglich sein, einen Artikel und eine Menge zu wählen. Daraufhin soll der alte Artikel aus der Materialliste entfernt werden und der neue Artikel in die Materialliste hinzugefügt werden.
   • Ein Historieneintrag soll nach dem Verwenden der Funktion erstellt werden.
   • Wurde die Position bereits umgelagert, soll eine gegen Umlagerung gemacht werden. Ist die Materialliste bereits produziert, soll der jeweilige Artikel eingelagert werden.

Wenn aus einem PA eine Materialliste erstellt wird, sollen gleiche Artikel zu einer Position zusammengefasst werden. Diese Logik war vor dem Update vorhanden und soll nun nachgezogen werden.

Der Bericht zum Lieferplan ist eine Übersicht der Positionen aus dem Auftrag, die noch keinen Lieferschein haben.

1. Die "zu liefernden" Positionen (Spalte Restmenge) sind falsch, wenn im Auftrag mehrfach dieselben Artikel sind.

Bericht zur Filtereinstellung "Positionen in Lieferschein" ist richtig. Nur die vorausgewählte Filtereinstellung "Positionen ohne Lieferschein" ergibt falschen Bericht.

2. Einkaufs-Lieferplan ist auch zu prüfen und eventuell zu korrigieren.

Aktuell werden die DHL-Labels beim Erstellen in die Dateianhänge hinzugefügt. Nach dem Hinzufügen sollen die Etiketten noch zusätzlich heruntergeladen werden.