Beim Einlagern von EK-Lieferscheinen kommt es zu einer Fehlermeldung. Diese sagt aus, dass nicht genügend Bestand zu auslagern vorhanden sind. Die Prüfung bezieht sich auf Verkaufs-Lieferscheine und ist im Einkauf falsch.

EK-Lieferscheine sollen ohne Fehlermeldung ausgelagert werden können.

Für SEPA-Lastschriften wurde die Creditor-ID im Verwendungszweck implementiert. Bei SEPA-Überweisungen soll diese Creditor-ID im Verwendungszweck nicht angegeben werden.

Falls man einen Lieferschein zum Lieferdatum ein- oder auslagert, ist dies nicht möglich, wenn das heutige Datum als Lieferdatum gesetzt ist. Es kommt die Meldung, dass das Lieferdatum in der Vergangenheit liegen muss.

Bei der Prüfung des Lieferdatums soll das heutige Datum verwendet werden können.

In der Chemiebranche müssen oft Sicherheitsdatenblätter (SDBs) an Kunden weitergereicht werden. Diese werden meist durch ein Drittprogramm erstellt und in einem bestimmten Verzeichnis abgelegt.

Mit Ticket #20687 wurde das Feature erweitert:

• Kundenspezifische SDBs als Textfeld in den Artikel-Stammdaten anlegen und den Inhalt speichern
• Die Namen von SDBs werden über ein bekanntes Muster aufgelöst, dieses Muster soll angegeben werden können
• z.Z. wird die Sprache in der SDB nicht beachtet. Sie soll ebenfalls erkannt werden. zum Versand von SDBs in Emails
• SDBs die Kundenspezifisch sind sollen beim Versand von Emails an den Kunden bevorzugt werden
• SDBs sollen gesammelt über eine einzelne Checkbox angehängt werden können

Dieses Feature soll nun auch in den Standard portiert werden.

Im Moment ist es nicht möglich, einen Lieferschein zu einem bestimmten Tag ein- oder auszulagern (nur aktueller Tag möglich). Dies wird z. B. benötigt, um rückwirkend die tagesaktuellen Lagerbestände von einem Fremdlager abzubilden. Daher soll es möglich sein, die Ein-Auslagerungen über Lieferscheine zum Zeitpunkt des Lieferdatums durchzuführen.

1. Lager bekommen Checkbox "Fremdlager" mit Tooltipp "Lagerbewegung erfolgt zum Lieferdatum"
2. Zusätzlich zur Meldung das Ein-/Auslagerung im Lieferscheinen durchgeführt wurde auch die Info: "Lagerbewegung erfolgt zum Lieferdatum"
3. Prüfung: Lieferdatum muss in der Vergangenheit liegen und darf nicht leer sein
4. Prüfung: Auslagerung darf kein Negativbestand erzeugen (abhängig von Mandantenkonfiguration)

Bei Lastschriftmandaten wird im Verwendungszweck die Gläubiger-ID (Creditor-ID: DExxZZZxxxxxxxxxxx) angegeben.
Diese Gläubiger-ID fehlt im Verwendungszweck bei Lastschriften aus dem odyn-erp und soll mit übergeben werden.

Der Lieferplan (Verkauf/Berichte/Lieferplan) soll nach Warengruppen gefiltert werden.
Aktuell kann im Filter ("In Bericht aufnehmen") nur die Warengruppe hinzugefügt werden aber nicht darauf eingeschränkt.

Der Link zum Wiki auf der Startseite des ERP-Systems zeigt im Moment auf die FAQ-Seite des Wikis
Dieser Link soll auf die folgende Seite angepasst werden: "https://wiki.opendynamic.de/".
Dadurch wird der Benutzer automatisch auf die Startseite der Wiki weitergeleitet.
Die Beschreibung soll von "Wiki und FAQs:" auf "Wiki Startseite:" angepasst werden

Buchen von Einkaufs-RG aktualisiert Artikel-Stammdaten (je nach Einstellung in Mandantenkonfiguration):
a) EK und Lieferanten-Preis von Artikel-Stammdaten
b) Einträge in der Preishistorie

Bei diesem Vorgang müssen folgende Punkte angepasst werden:

1. Ein aktuellerer EK-Preise (mit neuerem Datum) als in der Historie vorhanden, soll übernommen werden. Aktuell wird der EK-Preis nicht aktualisiert, wenn ein aktuellerer Lieferanten-Preis vorhanden ist. Auch wenn es aktuellere Lieferanten-Preise gibt, soll der EK-Preis aktualisiert werden.
2. Wird ein Lieferantenpreis geändert ist die Spalte "zum Datum" zu aktualisieren (aktuelle erfolgt kein Eintrag)

Folgende Dinge sind aufgefallen und sollten behoben werden:

1. Bei einem Fehler (z.B. fehlende Steuerzone) kommt der Fehler pro Position. Bei vielen Positionen wird es dadurch sehr unübersichtlich. Deshalb sollten gleiche Fehler nur 1x ausgegeben werden.

2. Der Fehler "Can't call method "iso" on an undefined value" sollte durch eine benutzerfreundlichere Fehlermeldung ersetzt werden

Für Kreditoren-/Debitorenbuchungen wurde der Datev-Export um die Bemerkungen erweitert.
Diese Erweiterung soll auch für Dialogbuchungen umgesetzt werden.

In Ticket #21324 wurden folgende Fehler behoben:

• Beim Massendruck von Rechnungen wird die primäre Rechnungsadresse nicht ausgegeben, sondern die Adresse aus den Basisdaten des Kunden.

• Zusätzlich werden die Preise nur mit zwei Nachkommastellen ausgegeben (definiert ist eine Ausgabe von vier Nachkommastellen).

• Außerdem werden bei der Massenerstellung Werte wie z.B. die Rechnungsadresse nicht korrekt übernommen, wenn diese im Lieferschein nicht vorhanden ist.

Diese wurden nun in den Standard portiert.

Aktuell kann eine reservierte Positionen im Auftrag gelöscht wird und dessen Reservierung bleibt weiterhin bestehen. Implementierung erweitern um:
a) Reservierungen mit den gelöschten Auftrags-Position auflösen (wie in Lieferscheinen).
b) Falls Reservierungen ohne Auftrags-Position vorhanden sind, werden alle mit einem Datenbank-Upgrade aufgelöst.

Bei der ERP-Installation unter Ubuntu 24 kommt es zu Fehlern im ERP:

1.) Beim Öffnen von Aufträgen/Angeboten kommt es zu folgendem Fehler: dotransaction() failed - DBD::Pg::st execute failed: ERROR: trailing junk after parameter at or near "$1O" LINE 35: …g ON (p.partsgroupid = pg.id) WHERE o.trans_id = $1ORDER BY… ^ at /opt/prod/odyn-erp/SL/DBUtils.pm line 148.
2.) Beim Drucken von E-Rechnungen kommt es zu folgendem Fehler ! LaTeX Error: File `puenc-greek.def' not found.

In Ticket #21429 wurden Fehler bei der ERP-Installation unter Ubuntu 24 behoben.
Diese sollen nun in den Standard portiert werden.

Beim Drucken von Einkaufslieferscheinen kommt folgende Fehlermeldung: DBD::Pg::st execute failed: ERROR: trailing junk after parameter at or near "$1AND" LINE 16: WHERE 1=1 AND v.id = $1AND v.vendornumber = $2 ^ at /opt/test/odyn-erp/SL/DBUtils.pm line 148.

Das PDF-Dokument wird trotzdem erstellt und unter dem Reiter "Dokumente" angezeigt.

Einkaufslieferscheine sollen ohne Fehlermeldung gedruckt werden können.

Aktuell ist der Ladecode für Kosovo XK und dieser führt bei der Validierung von E-Rechnungen zum Fehler. Die Mustang Validierung erwartet 1A für Kosovo und deshalb wird zukünftig diese genutzt.

Sobald ein Artikel kundenspezifischen Einträgen hat, wird bei der Abfrage nach gültigen/gesperrten Artikeln nicht mehr auf die Artikelsperre geachtet.

Die Prüfung soll angepasst werden.

Nicht steuerbarer Umsatz kann nicht wie bisher in Rechnungen gebucht werden. Für den Artikel Schadenersatz wurde eine Buchungsgruppe angelegt und richtiges Sachkonto/FiBu-Konto zugewiesen. Aktuell wird in der Steuerzone Inland der Standard Steuersatz erwartet und 0% führt zu einem Fehler.

Lösung:

1. Die E-Rechnung benötigt eine weitere Steuerzone für "Nicht steuerbarer Umsatz" (Punkt ist erledigt)
2. Bei dieser Steuerzone soll kein Steuersatz in die XML übermittelt werden (aktuell werden 0% übergeben und führt zu Fehlermeldung)

Folgende Verbesserungen werden für die E-Rechnung implementiert:

1. Für eine höhere Genauigkeit speichert das ERP-System den rabattierten Positionspreis mit mehr als zwei Nachkommastellen. Erst der Gesamtpreis der Position wird auf volle Cent gerundet. Da die E-Rechnung nur Preise mit zwei Nachkommastellen erlaubt, wird der Preis dort mithilfe eines Preisfaktors übermittelt. Der maximale Preisfaktor entspricht dem höchsten im ERP-System hinterlegten Preisfaktor. Beispiel: Ein rabattierter Einzelpreis von 2,442 wird mit einem Preisfaktor von 10 als 24,42 übermittelt.
2. Für das richtige Fälligkeitsdatum wird der Wert von BasisPeriodMeasure auf den Wert des "Zahlungsziel Netto" geändert.
3. Zukünftig werden die Werte, aus dem neuen Feld "Handelsregister" in der Firmierung, mit übergeben.

Wenn man aus einem Auftrag eine Rechnung erstellt, werden Positionen mit Minusmenge entfernt
und nicht an die Rechnung übergeben. Dasselbe gilt auch für die Erstellung eines Lieferscheins.
Positionen mit Minusmenge werden benötigt, damit in E-Rechnungen Nachlässe oder Rabatte verwendet werden können.

Beim Erstellen von Rechnungen und Lieferscheinen aus Aufträgen sollen Positionen mit Minusmengen nicht entfernt werden.

Hat der PDF-Dateinamen einer erhaltenen E-Rechnung ein Leerzeichen, dann schlägt die Validierung der E-Rechnungen fehl.
E-Rechnungen mit Leerzeichen im PDF-Dateinamen sollen ohne Probleme validiert werden.

Für den Upload der Sicherheitsdatenblätter muss die Prüfung des Dateinamens angepasst werden, da sonst der Upload nicht funktioniert.

Die Prüfung soll auf folgenden Dateinamen prüfen:

1 Prefix "SDS" | 2 Wert welcher im ERP eingetragen wird | 3 Versionsnummer ohne dem V (1, 2, …) | 4 Land (DE, GB, …).pdf
Dabei ist "|" durch ein "_" zu ersetzen.

Hinweis: Es kann vorkommen, dass es keine Versionsnummer gibt. Dann soll dies wie die Versionsnummer "1" behandelt werden.

Ein EDI-Auftragsimport kann nicht durchgeführt werden, wenn dieser ungültige Artikel enthält. Die gleiche Logik soll auch für gesperrte Artikel implementiert werden.

Bei Lieferscheinen für Servicetechniker (Lieferscheine mit Kunde "Servicetechniker") kann es bei der Stornierung
von Umlagerungen vorkommen, dass Lagerbestände von Artikeln in Minus gebucht werden.
Hier wird nicht auf die Mandantenkonfiguration geprüft (Minusbestände erlaubt/nicht erlaubt).
Dies betrifft auch manuelle Auslagerungen aus normalen Lieferscheinen.

Bei der Stornierung soll die Mandantenkonfiguration berücksichtigt werden und nur ins Minus gebucht werden,
wenn dies erlaubt ist.

E-Rechnungen im PDF/A-Format müssen bestimmte Anforderungen erfüllen, um die langfristige Lesbarkeit und maschinelle Auswertbarkeit zu gewährleisten. Daher müssen einige Dinge in den Druckvorlagen angepasst werden:

Briefpapiere:
Ein wichtiger Aspekt dabei ist, dass diese Rechnungen keine Interpolationen enthalten dürfen.
Da jedoch die Briefpapiere (stationery.pdf) Interpolationen enthalten, müssen diese angepasst werden.

Währungen:
Aktuell verwenden die Druckvorlagen das Paket "eurosym". Das Problem ist, dass PDF/A ein Standard für die Archivierung von PDFs ist, und er verlangt, dass alle Schriftarten vollständig eingebettet und die Glypheninformationen korrekt sind.

Dies ist jedoch im Paket "eurosym" nicht der Fall. Aus diesem Grund muss das Paket "eurosym" entfernt werden und anstelle des Befehls "\euro" sollte der Befehl "\texteuro" verwendet werden, der mit der PDF/A-Konformität kompatibel ist.

Um die Vorgaben von ZUGFeRD zu erfüllen, muss sichergestellt werden, dass die E-Rechnung den Anforderungen sowohl des
PDF/A-3a-Standards für die PDF-Dokumente als auch den XML-Spezifikationen entspricht.

Dafür ist es notwendig, die Druckvorlagen der PDF-Dateien anzupassen, damit die Rechnung ein gültiges PDF/A-3-Dokument ist. 

Um fehlerhafte XML-Daten zu vermeiden, sollte eine zentrale Funktion zur Überprüfung der XML-Dateien mithilfe einer XSLT-Datei entwickelt werden. Diese Überprüfung sollte nach dem Drucken und vor dem Import erfolgen, um sicherzustellen, dass die XML-Daten korrekt und gültig sind.

Zur Vervollständigung des Exportes sind folgende Felder zu erweitern:

• Erweiterung der -> Steuerzonen (5305. und Steuerbefreiungsgründe (VATEX) -> Lieferbedingungen (INCOTERMS) um ein Dropdown mit den entsprechenden Codes.

• [[ Kommentare ]] aus der Artikelnummer und Artikelbeschreibung entfernen

• Fehlerhafte Gruppierung der Steuern bei mehreren Buchungsgruppen mit verschiedenen Konten

• Fehlerhafte Menge bei Positionen als Überschrift

• Fehlerhaften Positionsnummern bei Positionen als Zwischensummen

Außerdem wurden Elemente zum besseren Nutzererlebnis hinzugefügt:

• Hinzufügen eines Hilfe-Buttons in die Actionbar von "Einkaufsrechnung von Scanner hinzufügen"

• Hinzufügen eines Links bei Fehler in der Validierung

• Flash-Meldung, wenn die Validierung gestartet wird

Beim Drucken mit einer anderen Währung und einem abweichenden Wechselkurs wurden die Werte doppelt umgerechnet
Zudem soll die Warnung den Wechselkurs berücksichtigen.
Dadurch werden diese fehlerhaften Meldungen bei anderen Währungen vermieden. 

Falls der Druck eines PDF-Dokuments für eine E-Rechnung nicht funktioniert,
werden die automatischen Mails für wiederkehrende Rechnungen nicht versandt.

Falls ein PDF-Dokument nicht erstellt werden kann,
soll der Task für wiederkehrende Rechnung weiter durchgeführt werden.
In der zusammengefassten Mail soll über die Nichterstellung des PDF-Dokumentes informiert werden.

E-Rechnungen dürfen keine negativen Preise enthalten.
Jedoch ist es manchmal notwendig, negative Preise in Rechnungen einzugeben (zum projektbezogener Rabatt).
Um dies zu gewährleisten, soll die Menge als Minusbetrag eingegeben werden, damit der Preis auch ins Minus geht.

Die Eingabe einer negativen Menge ist aber in Aufträgen (aus denen die Rechnungen entstehen) unterbunden und
kann deshalb nicht genutzt werden.

In Aufträgen sollen negative Mengen eingeben werden können.

In Produktionsaufträgen existiert ein Attribut "produziert". Zusätzlich ist es möglich, einen "Status" anzuzeigen und zu führen.
Dieser zeigt ein genaueres Bild über den Zustand des PA an. Grundsätzlich lässt sich aus dem Status ablesen,
ob ein PA produziert ist oder nicht, somit ist das Attribut "produziert" unnötig.

Das Attribut "produziert" soll nicht mehr geführt werden. Die Information über den Zustand des PAs soll über den "Status" erfolgen.

Wird bei einer SEPA-Anweisung mehrere Zahlungen gruppiert, wird der gesamte gruppierte Betrag der letzten Rechnung zugewiesen. Dadurch kommt es beim manuellen Verbuchen der Zahlungen für diese SEPA-Anweisung zu einem Fehler.
Der komplette Betrag wird der angegebenen Rechnung in der SEPA-Anweisung zugewiesen und nicht für alle Rechnungen aufgeteilt.

Um das Problem zu umgehen, sollen in den SEPA-Anweisungen zu gruppierten Zahlungen, alle Rechnungen angezeigt werden. Außerdem sollen gruppierte Zahlungen korrekt in den SEPA-Exporten der Rechnung angezeigt werden.

Falls die Spalte "Bestellnummer des Kunden" im Bericht zum Lieferplan ausgewählt wird,
wird diese nicht mit in den Export (PDF und CSV) übernommen.

Beim Export des Lieferplans sollten alle angezeigten Spalten auch exportiert werden.

Wenn sich ein Benutzer zum ersten Mal am ERP-System anmeldet, wird folgende Fehlermeldung angezeigt:
"Can't call method "cfg_value" on an undefined value at /opt/erp/odyn-erp/bin/mozilla/login.pl line 69."

Analyse:
Beim Erstellen von neuen Benutzern wird in der Authentifizierungs-Datenbank der Wert "cfgkey = odynversion" nicht angelegt. Dadurch kommt es beim Anmelden zu der Fehlermeldung.

Beim Erstellen von neuen Benutzern soll der Wert automatisch gesetzt werden.

In der Auftragsübersicht wird in der Spalte "Lieferschein erstellt" angezeigt, ob der Lieferschein mit kompletter Menge erstellt wurde. Derzeit wird davon ausgegangen, dass sie anzeigt, ob überhaupt ein Lieferschein erstellt wurde.

Um Verwirrung zu vermeiden, sollte die Spalte in "LS mit kompletter Menge" umbenannt werden.

Die Schnellerfassung von Verkaufsaufträgen hat falsche Steuerzone bei Kunden, die nicht "Inland" sind.
Mit dem Ticket #17794 wurde das Feld Steuerzone aus den Stammdaten ausgeblendet, da nun automatisch.
Die Schnellerfassung arbeitet immer noch mit Feld Steuerzone aus den Stammdaten.

Auf die neue automatische Ermittlung der Steuerzone umstellen.

Die Stornierung der Einlagerung von EK-Lieferscheinen mit externen Lieferanten kann nicht durchgeführt werden.
Der Button "Einlagerung Stornieren" ist ausgegraut und es kommt die Meldung "Dieser Beleg ist produziert und eingelagert"

Die Stornierung soll bei einer Einlagerung ohne Fertigung immer funktionieren.
Außerdem ist bei der Reservierung für externen Lieferanten in der Spalte "Dokument" kein Wert vorhanden.
Dies soll verbessert werden.

Nachdem ein Auftrag importiert wurde, wird die primäre Rechnungsadresse (falls vorhanden) nicht automatisch ausgewählt.
Dies hat zufolge, dass durch den Workflow die Rechnungen auch keine primäre Rechnungsadresse bekommen und diese dann in den Web-EDI Dateien nicht berücksichtigt wird.
Außerdem wird die interne Bemerkung aus den Kundenstammdaten nicht übernommen.

Wird ein Auftrag importiert, soll die interne Bemerkung übernommen und die primäre Rechnungsadresse automatisch ausgewählt werden (falls vorhanden).

Die Funktion "Buchen & Drucken" berücksichtigt aktuell die keine Kopfrabatte. Dadurch ist das PDF-Dokument ohne und das
ERP-Dokument mit Kopfrabatt. Wird erneut Export/Drucken durchgeführt, ist das PDF-Dokument mit dem Kopfrabatt.

Die Funktion "Buchen & Drucken" soll erweitert werden und die Kopfrabatte berücksichtigen.

Beim Massendruck von Rechnungen wird die primäre Rechnungsadresse nicht ausgegeben,
sondern die Adresse aus den Basisdaten des Kunden.
Zusätzlich werden die Preise nur mit zwei Nachkommastellen ausgegeben (definiert ist eine Ausgabe von vier Nachkommastellen).

Der Ausdruck einer Rechnung über den Massendruck soll gleich dem Ausdruck direkt aus der Rechnung sein.

Außerdem werden bei der Massenerstellung Werte wie z.B. die Rechnungsadresse nicht korrekt übernommen,
wenn diese im Lieferschein nicht vorhanden ist.
Daher sollten die Werte wie im Workflow Lieferschein zu Rechnung aus dem Auftrag übernommen werden.

Das Hauptziel ist, das Angezeigte Daten, aus dem ERP-Dokument, auch im Web-EDI-Export zu finden sind. Aktuell ist die GLN von der Rechnungsadresse-Primär (wenn in Stammdaten angelegt) immer im Web-EDI-Export. Auch wenn im ERP-Dokument (Rechnung) keine Rechnungsadresse-Primär ausgewählt ist.

GLN aus Reiter-Basisdaten => Rechnungsempfänger = Kunde = Warenempfänger -Bei vorhandener Rechnungsadresse-Alternativ (im ERP-Dok.), ist diese GLN => Rechnungsempfänger -Bei vorhandener Rechnungsadresse-Primär (im ERP-Dok.), ist diese GLN => Rechnungsempfänger (Bei Rechnungsstellung ist diese vorausgewählt) -Bei vorhandener Lieferanschrift (im ERP-Dok. auch temporäre), ist die GLN => Kunde und Warenempfänger

GLN von Lieferant = Mandantenkonfiguration/Verschiedenes/Einstellungen für WebEDI/GLN GLN von EDI-Kundengruppe = Benutzerdefinierte Variablen/EDI-Kundengruppe/Kunde (GLN aus Reiter-Basisdaten)

Hinweis: Im Web-EDI-Export ist folgende Konstellation möglich: Die GLN von BY(Kunde) <> DP(Warenempfänger). Im odyn-ERP ist aktuell diese Konstellation nicht möglich, weil dieser Fall in der Praxis noch nicht vorgekommen ist.

Bei einer Abfüllung direkt auf einen Kundenauftrag wird nicht die für die Abfüllung reservierte Charge genommen. Dies führt bei der Abfüllung zu Fehlern.

Bei einer Abfüllung soll die jeweilige reservierte Charge verwendet werden.

Das Kopieren von mehreren Positionen im PA/ML und einfügen an gewünschter Position fehlt aktuell.

Dazu sollen neue Funktion implementiert werden:
1) Mehrere Positionen können mit der Checkbox ausgewählt werden
2) Neuer Button "Kopiere Pos." neben "Mehrere Artikel hinzufügen"
3) Dialog mit Frage an welcher Position soll eingefügt werden

Aktuell kann es vorkommen, dass Nutzer nicht bemerken, dass ein Update durchgeführt wurde oder nicht das Changelog zum aktuellen Update kennen.

Um dies zu verhindern, sollte beim erstmaligen Öffnen des ERP-Systems nach einem Update ein Dialogfenster angezeigt werden. Dieses soll auf die neue Version des ERP-Systems aufmerksam machen und mit einem Link auf die Changelogs verweisen.

Damit die Erweiterungen auch im Standard genutzt werden können, soll die Anbindung der Erweiterungen in den Standard eingefügt werden.

In den Debitorenbuchungen soll es möglich sein, Dateien des eingebundenen Scanners hochladen zu können.
Das Hochladen soll über den Button "Original vom 'Default Scanner' hinzufügen" im Reiter "Dokumente" der Debitorenbuchung ermöglicht werden. In der Rechteadministration gibt es bereits das Recht "Verkaufsbelege importieren vom Scanner oder von Email", dieses soll in "Verkaufsbelege zu Debitorenbuchung importieren" umbenannt werden.
Nur falls der Benutzer dieses Recht hat, soll der Import von Scan-Dateien in Debitorenbuchungen durchgeführt werden können.

Hat ein ERP-Dokument ein ungültiges (im Backend nicht verfügbar) Dokument und ein gültiges Dokument, dann werden beide im "E-Mail verschicken" Dialog angezeigt.

Dafür muss man bei Belegausdruck mitschicken "Einen bereits erstellten Belegausdruck mitschicken" auswählen. Nun wird bei "zuletzt erstellte Belegausdrucke" sowohl der gültige als auch der ungültige Beleg angezeigt.

Es sollen nur gültige Belege angezeigt und auswählbar sein.

In Stammdaten/Lieferanten/mehr/Vertragsübersicht sind einige Punkte aufgefallen, die verbessert werden sollen:

1. Die Liste der Verträge soll vom neusten Vertrag absteigend sortiert sein

2. Vertragserweiterungen (ohne Ablage) soll nicht in die Liste mit aufgenommen werden

3. a) Es soll eine neue Spalte mit dem Titel "Gültig/Ungültig" hinzugefügt werden.
       Diese soll anzeigen, welchen Gültigkeitsstatus der Vertrag hat.
   b) Überschreitet ein Vertrag sein Ablaufdatum, soll er automatisch auf ungültig gesetzt werden.

4. Momentan ist das Feld zur Angabe der Vertragslaufzeit ein Freitextfeld.
   Dieses soll in ein Dropdown-Menü geändert werden.
   Die Optionen, die zur Auswahl stehen sollen, sind wie folgt: (1/1, 1/2, 1/4, 1/12 und "keine").

5. a) Um den Kündigungstermin anzugeben, soll die Angabe der Anzahl in einem Freitextfeld erfolgen und die Angabe der Einheit über ein Dropdown-Menü mit der Auswahl zwischen Tagen oder Monaten
   b) Der Kündigungstermin soll aus Enddatum und Kündigungsfrist errechnet werden.
   c) Wiedervorlagen sollen nach Angabe, mit Vorlauf von x Tagen, vor Fristende erstellt werden.
   Dabei soll erst zum angegebenen Zeitpunkt die Wiedervorlage erstellt werden.
   Wiedervorlagen sollen dem Ansprechpartner des Vertrages (neues Feld) zugewiesen werden.

6. Bei Überschreitung des Kündigungstermins (in der Spalte Termin) sollen alle anderen Termine auf den nächstmöglichen Termin gesetzt werden.

   • Dabei ist zu beachten, dass mögliche bereits erstellte Wiedervorlagen ebenfalls angepasst werden müssen. Hierzu wäre ein Task-Server, der die Datumsvergabe und Wiedervorlagen handhabt, eine mögliche Lösung.

7. a) Sortierung der Spalten wie in anderen ERP-Berichten hinzufügen
   b) Export für PDF und CSV ist funktioniert nicht und soll gefixt werden. Momentan löst der Klick auf den jeweiligen Button zum Export keine Reaktion aus.

8. Der vorhandene Nummernkreis für die Vergabe der Ablage-Nr. (unter Mandantenkonfiguration / Nummernkreise / Letzte Ablagenummer)
   a) Es soll eine Lösung für Probleme gefunden werden, dass Sonderzeichen nicht als Präfix oder Suffix nicht im Nummernkreis verwendet werden können.
   b) Für Ablagen, die eine Nummernkreis besitzen, soll die Möglichkeit bestehen ein Trennzeichen
   wie ("/", "-", "," oder ".") zu vergeben. Es soll je nach Nutzerangabe vor oder nach diesem hochgezählt werden.
   c) Gleich zu der Vergabe von Rechnungsnummern soll beim Zurücksetzen auf eine kleinere Nummer eine noch nicht verwendete Nummer verwendet werden. Somit können Lücken im Nummernkreis geschlossen werden.

9. Zu allen Überschriften sollen Tooltips hinzugefügt werden, die Inhalte werden zu einem späteren Zeitpunkt hinzugefügt.

10. Alte Verträge können nur umbenannt werden, da sich ein anderer Dialog öffnet.
    Die Bearbeitung alter Verträge muss genauso möglich sein wie die Bearbeitung neuer Verträge.

11. Die Ablagen sollten als "elektronisch" gekennzeichnet werden können, damit sie leicht unterschieden werden können. Hierzu soll eine zusätzliche Checkbox neben der Ablagenummer hinzugefügt werden.

Background Jobs wurden mit einer Funktion versehen, die dafür sorgt, dass durch den Benutzer ausgelöste Background Jobs (z.B. Csv-Import/Export, Massendruck, etc.) Fehlermeldungen an den Benutzer weitergeben. Bei anderen Hintergrund-Jobs, die automatisch ausgeführt werden, ist das jedoch nicht notwendig, da die Fehlermeldung auch in der History hinterlegt wird und der Benutzer nicht explizit informiert werden muss.

Es soll möglich sein, Background Jobs bei der Implementierung zu markieren, um festzulegen, ob sie Fehler weiterreichen sollen oder nicht. Standardmäßig soll kein Fehler weitergereicht werden. Die Weiterreichung soll jedoch bei allen Background Jobs, die durch den Benutzer aus dem ERP-System ausgelöst werden können, aktiv sein.

Buchen und Drucken werden oft direkt nacheinander ausgeführt.
Es soll möglich sein, Rechnungen mit nur einer Aktion direkt zu Buchen und zu Drucken anstatt die Operationen getrennt voneinander ausführen zu müssen.

In der Konfiguration von 'Wiederkehrende Rechnungen', zu Verkaufs-Aufträgen, soll die Einstellung 'Lastschrifteinzug' aus der Zahlungsbedingung kommen.

Deshalb sollen folgende Punkte implementiert werden:

1. Zukünftig soll der Wert dieser Checkbox an die Rechnung, aus der Zahlungsbedingung übergeben werden
2. Diese Einstellung aus der Konfiguration von 'Wiederkehrende Rechnungen' löschen

Wird eine Ansprechperson/Rechnungsadresse in den Stammdaten (Kunde/Lieferant) ohne Firmenname angelegt, soll dieser aus den Basisdaten (Reiter Rechnungsadresse) gezogen und gespeichert werden.

Die ERP-Hilfe-Seite in der öffentlichen Wiki (https://wiki.opendynamic.de/books/odyn-erp/chapter/erp-hilfe) soll über einen Button aus dem ERP-System erreichbar sein. Mit Hilfe dieses Buttons kann der Benutzer alle Artikel rund um die ERP-Hilfe auf einen Blick sehen.

Der Button soll unter dem Menüpunkt "Programm" zwischen "Support" und "FAQ" implementiert werden.

Bei der Auswahl von Unterkunden in ERP-Dokumenten muss der Benutzer zwei Schritte ausführen. Zuerst muss der Hauptkunde und danach, in einem extra Feld, der Unterkunde ausgewählt werden.

Um die Auswahl eines Unterkunden zu vereinfachen, soll der Unterkunde direkt über die Kundenauswahl gefunden und ausgewählt werden können. Wird ein Unterkunde in ein ERP-Dokument hinzugefügt, soll automatisch auch der Hauptkunde übernommen werden.

Nachdem eine Ansprechperson oder Lieferadresse in den Stammdaten von Kunden/Lieferanten gelöscht wird,
springt der Fokus vom Reiter "Ansprechperson"/"Lieferadresse" auf den Reiter Basisdaten.

Der Fokus soll nach dem Löschen auf dem jeweiligen Reiter bleiben.

Manchmal wird ein horizontaler und vertikaler Scrollbalken in den ERP Dokumenten angezeigt, dieser soll vermieden werden.

Rechnungen (Verkauf/Einkauf) sind "geschlossen" wenn Rechnungsbetrag exakt dem Zahlbetrag entspricht. Der neu hinzugefügte Status zu Rechnungen (rechts oben) soll diesen auch anzeigen.

Aktuell werden erfasste Gutschriften im Verkauf/Einkauf gleich als geschlossen angezeigt, ohne den Zahlungsabgleich.

Beim Versuch, eine Mahnung zu erstellen, wird eine Fehlermeldung ausgegeben.
Der Mahnvorgang soll fehlerfrei durchgeführt werden.

Unter Produktion/Verkaufslieferscheine/Sammellieferscheine erstellen funktioniert der Filter nicht richtig: bei gesetztem Versanddatum von/bis erscheinen Aufträge außerhalb der gewünschten Periode.

Der Filter nach Versanddatum berücksichtigt nur Werktage.
Zum besseren Verständnis wurde ein Info-Tooltip implementiert, der dieses Verhalten beschreibt.

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.

Das Ticket #20754 überarbeitet den Lieferplan im Standard. Mit dieser Implementierung kann der Standard portiert werden um das Fehlverhalten abzuschaffen aber sämtliche Features der Berichts beizubehalten.

Zur Zeit ist die Artikelsuche im ERP in zwei unterschiedlichen Arten vorhanden:
1) Zwei Felder für Artikel-Nummer und Artikel-Beschreibung = alte Artikelsuche
    -Als Trenner zwischen Teilzeichenketten:
       a) Prozentzeichen "%" für beliebige Anzahl Zeichen
       b) Unterstrich "_"  für 1 Zeichen
    -Feld Artikel-Nr. ODER Artikel-Beschreibung
    -Reihenfolge der Teilzeichenketten WICHTIG

2) Ein Feld für Artikel-Nummer/-Beschreibung = neue Artikelsuche (Artikelpicker)
    -Als Trenner zwischen Teilzeichenketten:
       a) Leerzeichen " " ersetzt das Prozentzeichen "%" für beliebige Anzahl Zeichen
       b) Unterstrich "_"  für 1 Zeichen
    -Feld Artikel-Nr. UND Artikel-Beschreibung
    -Reihenfolge der Teilzeichenketten UNWICHTIG

In ERP Dokumenten, wenn Artikel in die Positionstabelle hinzugefügt werden,
soll die Artikelsuche im ERP nur über eine Methodik erfolgen, so wie im Artikelpicker (Nr. 2, aber weiterhin über zwei Felder).

Hinweis:
Alle Berichtsfilter zu ERP-Dokumenten (Angebot, Auftrag, Lieferschein, Rechnung (EK und VK)), Artikel-Stammdaten und Berichten (Verkaufsbericht, ...)
deren Funktionsweise bleibt wie bisher (Teilstrings werden durch das "%"-Zeichen getrennt und dessen Reihenfolge ist wichtig).

Nachdem eine Ansprechperson oder Lieferadresse in den Stammdaten von Kunden/Lieferanten gelöscht wird, springt der Fokus vom Reiter "Ansprechperson"/"Lieferadresse" auf den Reiter Basisdaten.

Der Fokus soll nach dem Löschen auf dem jeweiligen Reiter bleiben.

Unter Umständen kann es sein, dass sich die Menge von Staffelpreise bei Lieferanten/Kunden ändern. Wenn die Menge in den Stammdaten von Artikeln angepasst wird, ändert sich nicht das Datum "Erneuter am".

Falls sich in den Artikelstammdaten die Menge von kunden/-lieferantenspezifischen Einträgen ändert, soll das Datum "Erneuert am" aktualisiert werden.

Zu ausgewählten Positionen vom Auftrag soll ein Lieferavis an den Kunden gesendet werden können. Dazu werden folgende Punkte implementiert:

1. Neue Druckvariante "Lieferavis"
2. Neue Textvorlagen implementieren "Verkauf: Lieferavis": a) Für Einleitung: "Verkauf: Lieferavis" wie beigefügt b) Für Schluss: "Verkauf: Lieferavis" wie beigefügt c) Für E-Mail: "Verkauf: Lieferavis" wie beigefügt
3. Nach Auswahl Druckvariante "Lieferavis" folgt Dialog "Lieferdatum" Auswahl von allen Werten zu Lieferdatum (Auftrag und verschiedene Positionen)
4. Übergabe der Positionen aus dem Auftrag mit gewähltem Lieferdatum
5. Neue Druckvorlage mit Lieferdatum als KW, Positionstabelle ohne Langtext, Einzelpreis und Gesamtbetrag
6. Name des PDF-Dokumentes Lieferaviszumxx.xx.xx_AByyyyyyy.pdf

1. Beim Einfügen eines Artikels in VK-ERP-Dokumente, soll der Listenpreis statt des Verkaufspreises verwendet werden, wenn der Verkaufspreis nicht vorhanden ist. Preisregeln sind weiterhin eine bevorzugte Preisquelle.

2. Im Workflow Angebot → Auftrag sollen die Stammdaten eines Artikels erweitert werden: a.) Neue Mandantenkonfig, die dieses Verhalten ein/ausschaltet b.) Neue Preisquelle: Aktualisiere VK-Preis, analog zu der EK-Preisquelle die Preise aktualisiert c.) Wenn die Mandantenkonfig an ist, erhalten Auftragspositionen, die aus einem Angebot erstellt, werden automatisch die neue Preisquelle d.) Wenn eine Auftragsposition mit der neuen Preisquelle gespeichert wird, werden die Stammdaten des Artikels aktualisiert. Sofern der Artikel keinen VK-Preis hat, wird der rabattierte Einzelpreis der Position eingetragen.

Durch beide Punkte ist zukünftig der Listenpreis ohne Rabatt und der Verkaufspreis mit Rabatt in den Stammdaten geführt.

Zur Zeit ist die Artikelsuche im ERP in zwei unterschiedlichen Arten vorhanden:

1. Zwei Felder für Artikel-Nummer und Artikel-Beschreibung = alte Artikelsuche -Als Trenner zwischen Teilzeichenketten: a) Prozentzeichen "%" für beliebige Anzahl Zeichen b) Unterstrich "_" für 1 Zeichen -Feld Artikel-Nr. ODER Artikel-Beschreibung -Reihenfolge der Teilzeichenketten WICHTIG

2. Ein Feld für Artikel-Nummer/-Beschreibung = neue Artikelsuche (Artikelpicker) -Als Trenner zwischen Teilzeichenketten: a) Leerzeichen " " ersetzt das Prozentzeichen "%" für beliebige Anzahl Zeichen b) Unterstrich "_" für 1 Zeichen -Feld Artikel-Nr. UND Artikel-Beschreibung -Reihenfolge der Teilzeichenketten UNWICHTIG

In ERP Dokumenten, wenn Artikel in die Positionstabelle hinzugefügt werden, soll die Artikelsuche im ERP nur über eine Methodik erfolgen, so wie im Artikelpicker (Nr. 2, aber weiterhin über zwei Felder).

Hinweis: Alle Berichtsfilter zu ERP-Dokumenten (Angebot, Auftrag, Lieferschein, Rechnung (EK und VK)), Artikel-Stammdaten und Berichten (Verkaufsbericht, …) deren Funktionsweise bleibt wie bisher (Teilstrings werden durch das "%"-Zeichen getrennt und dessen Reihenfolge ist wichtig).

Zu Gutschriften wird in folgenden Berichten in der Spalte "Anz. Dok." die Anzahl der Dokumente nicht angezeigt: Hauptmenü Verkauf/Rechnungen, Gutschriften & Debitorenbuchungen Hauptmenü Finanzbuchhaltung/Buchungsjournal

Wird bei einem ERP-Dokument fälschlicherweise ein falsches Projekt ausgewählt, kann dieses nicht mehr aus dem ERP-Dokument entfernt werden.

Projekte sollen in allen ERP-Dokumenten entfernt werden können.

Beim Versenden von Zahlungserinnerungen oder Mahnungen per Mail werden keine PDF-Dokumente mitgeschickt.

Beim Versenden von Zahlungserinnerungen/Mahnungen sollen die erstellten PDF-Dokumente mitgeschickt werden.

Unter "System/Finanzbuchhaltung/Konten anzeigen" können alle FiBu-Konten im ERP-System angezeigt werden. Wählt man hier ein bebuchtes Konto aus, kann man es ohne Probleme mit dem "Löschen"-Button löschen. Dies kann zu fehlerhaften Buchungen im System führen.

Um dies zu verhindern, soll der Löschen-Button ausgegraut werden, sobald das Konto bebucht ist.

Beim Auslagern von EK-Retouren-Lieferscheinen kommt folgende Fehlermeldung:

DBD::Pg::db selectallarrayref failed: ERROR: syntax error at or near ")" LINE 18: …countryid = (SELECT country_id FROM subsidiaries WHERE id=) ^ at /opt/prod/SL/DBUtils.pm line 166.

Der Lieferschein wird trotz Fehlermeldung ausgelagert.

Die Fehlermeldung soll nicht mehr angezeigt werden.

Wird der Bericht für die Lagerentnahme (Lager/Lagerentnahme ) für einen Monat ausgeführt, der keine 31 Tage hat, kommt eine Fehlermeldung:

Invalid day of month (day = 31 - month = 2 - year = 2024. at /opt/erp/ges/test/odyn-erp-ee/SL/Controller/Inventory.pm line 236.

Der Bericht soll für alle Monate ohne Fehlermeldung funktionieren.

Ein Erzeugnis, welches eine Dienstleistung in der Baukastenliste hat kann über "Lager/Lagerbestände/Erzeugnis fertigen" nicht gefertigt werden. Es kommt immer die Meldung, dass zu viel Einheiten der Dienstleistung im Lager vorhanden sind.

Da Dienstleistungen nicht eingelagert werden, soll das Fertigen von Erzeugnissen diese ignorieren.

Um Labels auch für die Einkaufs-Retouren-Lieferscheine über die DHL-API zu erstellen soll die DHL-Erweiterung auch für Einkaufs-Retouren-Lieferscheine zur Verfügung stehen.

Werden PAs oder AAs über die Produktionsübersicht gedruckt, wird im Pop-up für das Drucken ein HASH-Wert anstatt dem Dokumentennamen angezeigt.

Es soll der Dateiname statt dem HASH_wert angezeigt werden.

Aktuell ist das Erzeugen von Erzeugnissen im Lager mit der sofortigen Dezimierung von Bestandteilen verbunden. Es wird mehr Transparenz und Flexibilität bei diesem Prozess mit Chargen und MHD benötigt:

1. Wie ist aktuell die Reihenfolge bei der Dezimierung von Bestandteilen (FiFo Charge oder MHD)?
2. Die Chargen der Bestandteile a) Automatisch bestimmt = Standard (Wie aus Analyse zu Punkt 1., Ausgabe der verwendeten Bestände (Lager, Lagerplatz, Charge, MHD, Artikel und Menge). Es wird ein PA angelegt der die Erzeugnisse Chargenrein auf Positionen verteilt enthält. Der PA wird direkt produziert und dient nur der Protokollierung des Vorgangs.
3. Die Chargen der Erzeugnisse, über eine Einstellung a) Automatisch = Fortlaufende Nr. aus Nummernkreis, Standardverhalten als Fallback b) Kombination = 1x Erzeugnis-Charge pro Chargenkombination der Bestandteile
4. Die Mandantenkonfig für Erzeugung ohne Prüfung auf Bestand aktualisieren
5. Automatische Tests anpassen/erstellen um das neue Verhalten zu kontrollieren

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

In bestimmten Fällen ist eine Ausnahmen sinnvoll: Z. B. VK-Auftrag ist die Reparatur 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 ist erforderlich. In der Praxis werden diese zwei Aufträge gerne als ein Auftrag gesehen und behandelt.

Speziell zu einzelnen VK-Aufträgen werden zum Materialeinkauf EK-Aufträge erstellt. Dazu soll das eingekaufte Material sollen später dem Kunden in Rechnung gestellt werden. Hierzu müssen Mitarbeiter diese eingekauften Artikel manuell in ein VK-Dokument eintragen.

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".

Aktuell wird im Lager/Lagerbestand immer der Gesamt-Bestand angezeigt. Ein neuer Radiobutton zu Gesamt/Verfügbar/Reserviert ermöglicht die Bestandsanzeige zu Verfügbar und Reserviert.

1. Wählbare Bestandsanzeige zu Gesamt/Verfügbar/Reserviert: Gesamt = Verfügbar + Reserviert Verfügbar = Lagerbestand ohne Reserviert Reserviert = Nur Reserviert
2. Nur die Bestandsanzeige zu Reserviert erweitern um Spalte Dokument (wie in Lagerbuchungen). Somit erfolgt auch gleich die Anzeige für welches Dokument die aktuelle Reservierung ist.

Aktuell kann als Preisquelle eine Preisregel mit prozentualen Abschlägen, vom Stammdatenpreis, geführt werden. Dabei gelten folgende Regeln:

• Abschlag nur vom Stammdatenpreis möglich, nicht vom Preis einer Preisregel anwendbar
• keine Kumulierung von Abschlägen möglich, sondern der günstigste/höchste Wert gilt (bei selber Priorität)
• der Abschlag erfolgt gleich nach der Preisermittlung und ist somit vor dem Rabatt

Diese Funktion soll wie folgt verbessert werden:

1. statt in Prozenten soll ein Dezimaler/Absoluter Wert angegeben werden (um weniger Ähnlichkeit mit Rabatt zu haben)
2. Preisquelle kennzeichnen als Preisregel-Kombination: "Stammdaten mit Abschlag"

Es soll eine neue Kategorie analog zu den Warengruppen eingefügt werden, die genau wie die Warengruppe eine genauere Abgrenzung von der Gültigkeit von Preisregeln ermöglichen soll.

Es sollen, wie auch bei den Warengruppen, durch den Benutzer neue Gruppen angelegt und Artikeln zugewiesen werden. Es ist nicht verpflichtend eine Zusatzkategorie zu setzen

Die Preisregeln sollen ebenfalls und die Bedingung "Zusatzkategorie" erweitert werden, erneut wie Warengruppen bereits funktionieren.

Die Methode "asdebuginfo" unter SL/DB/Object.pm kann verwendet werden um Rose-Objekte zu einem einfachen Daten-Hash umzuwandeln. Eine erweiterte Version dieser Funktion ist wünschenswert, da es oft vorkommt das die Daten von Rose-Objekten durchlaufen und in ein Formular geschrieben werden. Es soll eine neue Funktion geschrieben werden, die ähnlich wie "asdebuginfo" funktioniert aber erweiterte Funktionen bietet. Die Funktion: Nimmt ein Objekt als $self an, sowie %params. Gibt eine Hashref zurück die die benötigten Werte enthält. Es soll möglich sein in den params das Verhalten zu ändern indem Methodenaufrufe hinzugefügt werden können, deren Ergebnisse ebenfalls in der Hashref aufgenommen werden

Das User Interface zum Erfassen von Wiedervorlagen hat große ungenutzt Flächen.

Diese sollen reduziert und überarbeitet werden.

Die Inventur kann zu einem Stichtag ausgeführt werden. Dabei werden Reservierungen ebenfalls behandelt, indem sie als eigener Bestand aufgeführt werden. Es wird dabei das zugehörige Dokument angezeigt. Sollte jedoch zwischen dem Stichtag und dem Buchen der Inventur die Reservierung aufgelöst werden, wird das Dokument nicht mehr in der Inventur angezeigt, nur noch die reservierte Menge. Dieser Fall kann z.B. auftreten, wenn ein Lieferschein 10 Stück einer Ware vor dem Stichtag reserviert hat, jedoch vor dem Buchen der Inventur die Ware ausgelagert wird.

Auch wenn die Reservierung inzwischen nicht mehr existiert, soll das Dokument für das zum Stichtag reserviert war, korrekt angezeigt werden.

In Ticket #19947 wurde ein Upgrade-Skript erstellt, um den Steuersatz an Rechnungspositionen zu speichern. Wenn Kunden jedoch mehrere Firmierungen mit unterschiedlichen Ländern verwenden, kommt es zu Fehlern im Upgrade-Skript.

Ein händisch vergebener EK-Preis im Auftrag ändert sich, sobald im Feld "Menge" der Position "Enter" verwendet wird. Dabei wird der händisch vergebene EK-Preis mit dem EK-Preis aus den Stammdaten aktualisiert.

Der EK-Preis soll nur händisch oder über die Funktion "Artikel aktualisieren" geändert werden.

Beim Öffnen von Verkaufs-Aufträgen folgt Fehlermeldungen und der Auftrag wird nicht angezeigt.

Beim Öffnen von Aufträgen soll keien Fehlermeldung angezeigt werden.

Aktuell nutzen die Retouren-Lieferschein aus dem Einkauf und Verkauf die Vorlagentexte der Lieferscheine. Deshalb muss der Benutzer Informationen zur Retour in die Vorgangsbezeichnung oder Artikel-Beschreibung hinzufügen.

Eigene Vorlagentexte für Retouren-Lieferschein aus dem Einkauf und Verkauf würden dies erübrigen.

Bei der Erstellung von Kreditoren-/Debitorenbuchungen werden oft relevante Informationen im Feld "Bemerkungen" hinterlegt. Im Datev-Export werden diese Bemerkungen nicht mitexportiert.

Der Datev-Export soll um die Bemerkungen aus Kreditoren-/Debitorenbuchungen erweitert werden. Dafür werden neue Datev-Felder hinzugefügt: 1 a) Feld Nr. 0048 "Zusatzinformation – Art 1" mit "Vorgangsbezeichung" belegt, b) Feld Nr. 0049 "Zusatzinformation – Inhalt 1" max. 210 Zeichen aus der Vorgangsbezeichnung im ERP-Dokument (EK/VK RG) 2 a) Feld Nr. 0050 "Zusatzinformation – Art 2" mit "Bemerkung" belegt, b) Feld Nr. 0051 "Zusatzinformation – Inhalt 2" max. 210 Zeichen aus der Bemerkung im ERP-Dokument 3 a) Feld Nr. 0052 "Zusatzinformation – Art 3" mit "Kunde/Lieferant" belegt, b) Feld Nr. 0053 "Zusatzinformation – Inhalt 3" max. 210 Zeichen Kunden/Lieferanten-Nr. & Name im ERP-Dokument

Die Berichte zu Verkaufs- und Einkaufsbelegen sollen um die Projektbeschreibung erweitert werden. Die Projektnummern werden bereits ausgegeben und sollen um Projektbeschreibung erweitert werden. In allen Berichten soll der Abschnitt "In Bericht aufnehmen" die Checkbox Projektnummern erweitern auf "Projektnummern/Beschreibung".

1. Reiter "Rechnungsadresse" umbenennen in "Basisdaten"
2. Tooltip vor Feld "Kundennamen" mit Text "Standardadresse für alle ERP-Dokumente"
3. Reiter "Ansprechpersonen" umbenennen in "Weitere Adressen"
4. Hilfe-Button in der Actionbar zu Stammdaten/Kunden und Lieferanten und Verlinkung zur Wiki

Bei der Umsetzung von Ticket #18671 ist aufgefallen, das eine Funktion beim Buchen von VK-Rechnungen ausgeführt wird, die Erzeugnisse in Rechnungspositionen aufspaltet und in der Datenbank speichert. Danach werden diese Positionen jedoch gelöscht.

Es soll untersucht werden, warum dieses Verhalten implementiert wurde und ob es noch benötigt wird. Falls nicht, soll die Funktion entfernt werden um unnötige Datenbank-Transaktionen zu vermeiden.

Die Implementierung von Ticket #18671 soll daraufhin angepasst werden um mit den Ergebnissen dieses Tickets fehlerfrei zu funktionieren.

Es soll möglich sein, den Fokus des Berichts von der Menge in Auftragsposition die "ohne LS" sind, auf "mit LS" zu legen. Außerdem soll es möglich sein, von dem "Lieferschein" auf die "Auslagerung" in einem Lieferscheinen (LS), zu wechseln. Es ergeben sich über 2 Radio-Buttons die 4 Optionen mit 4 Ergebnissen:

1. Menge Auftragspositionen ohne Lieferschein 2. Menge Auftragspositionen mit Lieferschein
2. Menge Auftragspositionen ohne Auslagerung in LS 4. Menge Auftragspositionen mit Auslagerung in LS

Außerdem sollen die Optionen des Berichts erweitert werden:

• Auftragsstatus (offen/geschlossen/alle)
• Bestellnummer des Kunden
• In Bericht aufnehmen: Bestellnummer des Kunden

Der Bericht OP Saldo zu Kreditoren oder Debitoren zeigt aktuell Rechnungen, die zum Ende der Periode offen sind. Aktuell ist: Stichtag = Ende der Periode (diese Liste ist kürzer)

Oft wird die Darstellung mit offenen Rechnungen zum Anfang der Periode gewünscht. Wunsch: Stichtag = Anfang der Periode (diese Liste ist länger)

Lösung: Filter zum Bericht OP Saldo Kreditoren/Debitoren erweitern um Radiobutton für Stichtag a) Offene Rechnungen zum Ende der Periode b) Offene Rechnungen zu Beginn der Periode oder in der Periode gestellt

Die Mengen-Gutschrift hat als Preis-/Rabattquelle nicht den verknüpften Auftrag, wie "normale" Rechnungen das tun.

Mengen-Gutschriften sollen wie andere Rechnungen die Preis-/Rabattquelle Auftragspreis verwenden.

Das Debug-Statement $::lxdebug->dump(0, "allowmarge", $allowmarge); Erzeugt unnötige logdateien und soll entfernt werden

Bei Lieferant "Mainova AG" kann im Reiter "Dokumente" die Ablage "02/01/24" nicht umbenannt werden. Vermute das es am "/" liegt, vorher war es ".".

Bei Aufträgen mit einer anderen Währung als Euro und einem Wechselkurs, kommt es bei "als neu speichern" zu Fehlern Fehlermeldung: "'11,0000' doesn't look like a number at /opt/odyn-erp-server/bin/mozilla/oe.pl line 690." Diese Fehlermeldung wird nur angezeigt, wenn beim Neuspeichern die Option "mit Artikel kopieren (Positionstabelle)" ausgewählt wurde.

Der Fehler soll behoben werden.

Aktuell folgt Fehlermeldung wenn die PDF-Dokumente mit exportiert werden sollen: "Fehler! Export schlug fehl. Dateimanagement: Keine Zieldatei gefunden"

1. Bitte Fehlermeldung erweitern um die Information zu welcher Buchung die Zieldatei nicht gefunden werden kann: "Dateimanagement: Keine Zieldatei gefunden, zur Referenz / Rechnungsnummer ___"
2. Fix für Existierende Daten

Largebuchungen und -bestände können mit Chargen-/Seriennummern und Mindesthaltbarkeitsdatum(MHD) versehen werden. Dabei sollen Bestände getrennt für Chargen-/Seriennummern und MHD Kombinationen geführt werden. Der Lagerbericht zu Beständen beachtet dieses auch, gleicher Artikel und gleiche Chargennummer aber abweichendes MHD erzeugen getrennte Bestände.

Die Inventur kann verwendet werden um die Bestände im ERP der Realität anzugleichen. Hierbei wird das MHD jedoch nicht beachtet. Das MHD soll in der Inventur wie auch bei den Lagerbeständen beachtet werden. Nachdem die Bestände getrennt aufgelistet werden, müssen die Korrekturen auch mit MHD gebucht werden.

Wenn die Inventur durchgeführt wird, ist einer der erwarteten Fälle das weniger Bestand vorhanden ist als im ERP angegeben. Die Inventur korrigiert diesen Fehlbestand dann über eine negative Korrekturbuchung.

In diesem Fall kann es anscheinend vorkommen, das die Korrekturbuchung nicht korrekt auf "auf Lager" angewendet wird. Artikel speichern diesen Wert getrennt vom Lager, um Artikelstammdaten nicht unnötig zu verlangsamen.

Beim Datev Export können erzeugte PDF-Dokumente angehangen werden. Bei Debitorenbuchungen werden diese Dokumente jedoch nicht korrekt erkannt, das ERP erzeugt eine Fehlermeldung, obwohl das Dokument vorliegt.

Dokumente von Debitorenbuchungen sollen vom ERP korrekt erkannt werden

Zur Abbildung von Unterkonten und der Nutzung des Datev-Exports, soll der Datev-Export so angepasst werden, dass Konten nach dem Schema XXXX.XX exportiert werden können.

In der Mandantenkonfiguration soll im Reiter „Einstellungen für Datev“ die neue Option „Alternatives Kontonummernformat zulassen“ eingefügt werden. Mit dieser Konfiguration soll es ermöglicht werden, die Datev-Konformitätsprüfung um das neue Format zu erweitern.

Anpassung Entscheidungsbaum zur Ausgabe der ADR-Daten auf Lieferscheinen:

Handelt es sich um ADR?

• Bei Nein: normaler Entscheidungsbaum weiter machen
• Bei Ja: Ist der Verkehrszweig "Luftverkehr"
  • Bei Nein: Entscheidungsbaum weiter machen
  • Bei Ja: Dann ADR-Daten ausgeben (ohne weitere Prüfung)

Gewünscht ist das Service- und Wartungs-Aufträge eine Standard-Zahlungsbedingung (7 Tage netto) bekommen. Diese ist oft kürzer als die in den Stammdaten beim Kunden hinterlegte.

Daher solle folgende Punkte implementiert werden:

1. Erfassung von ERP-Dokumenten (Angeboten, Auftrag, LS, RG) über Menü Wartung und Service Unter System/Stammdaten/Abteilung erfolgt Erweiterung der Abteilung um die Auswahl einer Zahlungsbedingung. Diese soll dann mit der Auswahl der Abteilung auch gleich gesetzt werden.
2. Wird der Kunden oder die Abteilung ausgewählt/gewechselt soll nur eine kürzere Zahlungsbedingung übernommen werden a) Zahlungsbedingung der Abteilung muss kleiner sein als die des Kunden, um eingefügt zu werden b) Zahlungsbedingung des Kunden muss kleiner sein als die der Abteilung, um eingefügt zu werden

Aktuell haben die Zwischen- und das Nachkalkulations-Erzeugnis als EK-Preis die Summe aller EK-Preise von den Bestandteilen.

Zukünftig sollen die Zwischen-Erzeugnisse folgende EK-Preise haben:
 - ML1= 25% vom VK-Preis Fertig-Erzeugnis der Vorkalkulation
 - ML2= 55%
 - ML3=   0%
 - ML4= 10%
 - ML5=   0%
           = 90% vom VK-Preis Fertig-Erzeugnis der Vorkalkulation

Das Nachkalkulations-Erzeugnis bekommt im EK-Preis dadurch auch diese 90%.

1. In ML1-4 kann nur Positionsstatus "umgelagert" für die Erzeugung verwendet werden (Logik wie ML0. Aktuell werden auch Stornierte Positionen verwendet, siehe: Kommentar="storinert" Transfertyp=Korrektur und Kommentar="Standard-Umlagern storinert Materialliste(n)"
2. Die Bestandteile der Stückliste vom Erzeugnis .ML1-4 nur aus Positionsstatus "umgelagert" 3.Bei Materialliste Produzieren wird ein Erzeugnis gefertigt und somit Einstellung der Konfiguration beachten (System/Mandatenkonfiguration/Lager/Erzeugnis fertigen ohne Prüfung auf Bestand = Nein)
3. intern/extern Produzieren-Button mit Umlagern/Stornieren verfügbar bzw. nicht verfügbar machen. Es ist nur möglich zu Produzieren wenn alle Positionen umgelagert sind (ausgenommen externe Produktion).
4. Wenn eine umgelagerte Positionen können erst nach Stornierung der Umlagerung gelöscht werden
5. Wenn Reservierungen freigegeben werden, soll die Chargennummer dieser Bestände die Nummer des PA sein

Durch die Produktion werden Zwischenerzeugnisse angelegt, welche den Produktionszustand widerspiegeln. Bei der Erstellung wird kein Eintrag in der Preishistorie angelegt, was zur Folge hat das zu einem Stichtag der historische Preis nicht bestimmt werden kann.

Die Erzeugnisse sollen bei ihrer Erstellung einen Preishistorien-Eintrag anlegen.

Die Lieferung aller bestellten Produkte zusammen ist eine Komplettlieferung, sonst ist es eine Teillieferung. Die Teillieferung soll zukünftig in Lieferscheinen wie folgt behandelt werden:

1. Ganze Menge der Position fehlt, dann wird durch den Benutzer die Menge=0 gesetzt
2. Eine Teilmenge der Position fehlt, Die fehlende Menge wird vom Auftrag berechnet. Es kann das Nachlieferdatum angegeben werden
3. 0-Mengen oder Teilmengen bekommen in der PDF eine besondere Kennzeichnung: "Nachlieferung von Menge x __ am ..__ (oder in KW __) (Die Menge ist Differenz aus AB zu LS)
4. Workflow von LS zu Rechnung zukünftig ohne Positionen mit 0 Menge

Das Feature kann in der Mandantenkonfiguration unter "Features/Liefermengen Berechnung/Teillieferungen aktivieren" aktiviert werden

Artikel ohne Bestand sollen einen weiteren Dispositionstypen erhalten können. Artikel mit diesem Dispotyp haben immer einen Lagerbestand von 0, können aber ausgelagert und zur Produktion verwendet werden. In diesen Fällen wird eine Gegenbuchung durchgeführt, die den Bestand auf 0 hält. Die "ohne Bestand" soll sowohl für Waren als auch für Erzeugnisse verfügbar sein.

Im Wesentlichen geht es um:

1. Es wird kein Bestand geführt. Somit keine Überwachung, Einlagerung, Zählung, Korrektur…
2. Auslagerung/Verbrauch soll protokolliert werden
3. Auslagerung/Verbrauch soll kein negativen Bestand erzeugen

Beispiele für den Dispositionstypen "ohne Bestand":

• Wasser aus der Leitung (der Verbrauch wird protokolliert und brauch keinen Bestandsführung)
• Betriebsstoffe die über eine "Sichtprüfung" bestellt werden und keinen Bestandsführung benötigen
• Werbematerial …

Um die Rechte des Einkaufs und des Verkaufs besser trennen zu können, sollen zwei neue Rechte in das ERP-System implementiert werden.

1. Separate Rechte für Stammdaten/Kunden und Stammdaten/Lieferanten Im Moment können diese nur zusammen mit einem Recht an oder abgewählt werden. Beispiel: Der Vertrieb (Verkauf) soll seine Kunden sehen, darf aber keine Lieferanten sehen können. Dieses Beispiel kann im Moment nicht umgesetzt werden.

2. Erträge in den Suchformularen der Verkaufsdokumente soll per Recht an oder abgewählt werden können. Dies betrifft die Spalten "Ertrag" und "Ertrag prozentual". Diese Anzeigen sind auch in Dokumenten und der Positionstabelle vorhanden. Das neue Recht soll diese anzeigen ebenfalls an/ausschalten Beispiel: Ein Vertriebler soll Angebote erstellen/bearbeiten können, aber nicht die Erträge dieser sehen.

Wenn ein Stichtag gewählt wird, werden die Preise für die Bestände im Lager aus der Preishistorie der Artikel bestimmt. Dabei wird der gültige Preis zum Stichtag gewählt

In der Filtermaske des Lagerbestands soll ein Info-Icon für den Stichtag angegeben werden: "Wird ein Stichtag gewählt, dann werden die Preise für die Lagerbestände aus der Preishistorie der Artikel bestimmt."

Wenn aus einem Retour-Lieferschein eine Mengengutschrift erfolgt (Workflow) sollte dieser auch geschlossen werden sobald alle Positionen des Retour-Lieferscheins in Gutschriften enthalten sind.

Rechnungen können nur aus Lieferscheinen erstellt werden, wenn die Lieferscheine nicht geschlossen sind.

Diese Verhalten soll nun auch für Retouren-Lieferscheine und Gutschriften implementiert werden.

Retouren-Lieferscheine sind nicht Teil des normalen Lieferschein->Rechnung Workflows. Sie werden separat über Mengen-Gutschriften abgehandelt. Um bei der Massenerstellung von Rechnungen aus Lieferscheinen nicht versehentlich Retouren-Lieferscheine mit abzuhandeln, sollen diese nicht mehr im Bericht vorkommen.

Bei der Massenerstellung von Rechnungen aus Lieferscheinen sollen keine Retouren-Lieferscheine mehr gefunden werden.

Wenn in der Lieferadressensuche eine Lieferadresse gefunden wird, kann der Kunde/Lieferant über die angezeigten Links geöffnet werden. Dieses Feature funktioniert für Kunden ohne Probleme, führt bei Lieferanten jedoch zu einer Fehlermeldung.

Die Lieferadressen suche soll für Kunden und Lieferanten fehlerfrei funktionieren

Konten zur Gewinn- & Verlustrechnung und der Bilanz zeigen nicht die Werte aller Buchungen im Buchungsjournal.

Nach dem 04.01.23 ist der Fehler nur bei Zahlungen und der fehlenden Firmierung zu finden. Mögliche Ursache: a) Updateskript hat den Zahlungen keine Firmierung zugeordnet oder b) Die beiden Berichte berücksichtigen Zahlungen nicht richtig

Sobald im Lagerbestandsbericht ein Stichtag ausgewählt wird, werden keine EK-Preise für die Artikel angezeigt.

Wenn ein Stichtag ausgewählt wird, sollen die EK-Preise anhand der Preishistorie angezeigt werden.

Die Firmierungsadresse wird nicht an die Druckvorlage der Mahnrechnungen weitergegeben und somit kommt es beim Druck von Mahnrechnungen zu einem Druckfehler.

Mahnrechnungen sollen ohne Fehler gedruckt werden können.

Mit der Anpassung der Tabelle in der Mahnwesenkonfiguration wurde die Überschrift "PDF an E-Mail anhängen" entfernt. Dabei sind aber die Optionen der Spalte übrig geblieben und somit gibt es mehr Optionen wie Überschriften.

Die Optionen der entfernten Überschrift "PDF an E-Mail anhängen" soll auch entfernt werden.

Wird versucht, eine Preisregel zu öffnen, erscheint eine Fehler-Meldung im ERP.

Preisregeln sollen ohne Fehlermeldung geöffnet und verwendet werden können.

Wenn aus einem Lieferschein ein Retoure-Lieferschein erstellt wird, kann der Benutzer keine Lagerzuweisung definieren. Es wird die Meldung angezeigt "Die manuell eingetragene Chargennummer muss entfernt werden, um Lagerzuweisungen hinzuzufügen". Erst nachdem der Benutzer die Charge aus der Position entfernt hat, kann eine Lagerzuweisung definiert werden.

Dieses Verhalten ist sehr umständlich und kann bei größeren Retouren zu lange dauern. Beim Erstellen eines Retouren-Lieferscheins soll das Pop-up der Lagerzuweisung geöffnet werden.

Aktuell wird der Link zur Sendungsverfolgung nur im ERP, Reiter "DHL", angezeigt.

Damit diesen Link auch Kunde erhalten:
1) Wird eine erfasste E-Mail-Adresse an die DHL-API übergeben
2) Im Reiter DHL wird die Information angezeigt ob dieses Etikett mit oder ohne Übergabe der E-Mail-Adresse erstellt wurde
3) Einschalten und Konfigurieren der DHL-Erweiterung:
    a) Nach dem Einschalten erfolgt der Link nur auf Email-Adresse des Kunden
    b) Möglich ist Einstellung mit Link an Email-Adresse der Ansprechperson und falls keine vorhanden an die des Kunden.

Soll-Lieferscheine werden beim Rückmelden von Abfüllanweisungen an die tatsächlich produzierte Menge angepasst. Falls bei der Rückmeldung Anbruchgebinde verwendet werden, kann der Soll-Lieferschein nach der Anpassung nicht mehr ausgelagert werden.

Folgende Probleme treten auf und sollen gelöst werden:

1. Die Charge des Anbruchgebindes wird nicht an den Soll-Lieferschein übergeben (es fehlt das [[A]] in der Chargennumer)
2. Der Lieferschein kann nicht ausgelagert werden, da die Lagerausgänge für die neu erstellte Position nicht für die Charge des Anbruchgebindes definiert werden kann. Fehlermeldung: Die Bestände für die definierten Lagerausgänge an den folgenden Positionen sind nicht mehr verfügbar.

Wenn Produktionsaufträge als neu verwendet werden, erscheint die Fehlermeldung "DBD::Pg::db do failed: ERROR: LOCK TABLE can only be used in transaction blocks at /opt/prod/odyn-erp-ee/SL/DB/Helper/TransNumberGenerator.pm line 112."

Es soll möglich sein Produktionsaufträge fehlerfrei als neu zu verwenden

Beim öffnen eines ERP Dokuments werden alle verknüpften Belege auf ihren (intern geführten) Typen geprüft.
Zur Zeit haben Mahnungen keinen Typ und dies führte zu eine Fehlermeldung.

Der fehlende Typ bei Mahnungen wird nun beachtet und führt nicht zur Fehlermeldung.

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.

Um besser nachvollziehen zu können wie ERP-Dokumente geschlossen wurden, soll die Historie erweitern werden, sobald ein ERP-Dokument geschlossen wird. Folgende Daten sollen in die Historie eingetragen werden: Zeit = Datum und Uhrzeit wann ERP-Dokument geschlossen wurde Bearbeiter = Benutzer, der Aktion ausgeführt hat, die zum Schließen führt Aktion = Geschlossen Zusatz = Automatisch wenn automatisch, sonst den Dokumentennamen Info1 = falls automatisch "durch [Dokument] [Dokumentennummer]."; falls manuell "manuell "

Hierbei soll auch eine Anzeige mit "geschlossen" bzw. "offen" für Rechnungen eingebaut werden. Eine Rechnung ist geschlossen wenn der gezahlte Betrag größer oder gleich dem Rechnungsbetrag ist

In den Stammdaten eines Artikels können Verbrauch und Beschaffungszeit angegeben werden. Aus diesen Werten berechnet sich ein Meldebestand. Sobald dieser Meldebestand erreicht/unterschritten wird, wird der Artikel in einer Liste geführt um eine Nachbestellung zu verursachen.

Die Beschaffungszeit wird manuell geführt, der monatliche Durchschnitts-Verbrauch soll aber regelmäßig durch das ERP bestimmt und in die Stammdaten des Artikeln eingetragen werden. Hierfür soll ein Hintergrund-Job angelegt werden, welcher diese Berechnung vornimmt. Es sollen nur Artikel mit "Disposition nach Verkauf" aktualisiert werden.

Es soll dabei Konfigurierbar sein:

• Wie oft und wann wird diese Berechnung durchgeführt, einstellbar über das Anlegen des Hintergrund-Jobs.
• Über welche Periode wird der Durchschnittsverbrauch bestimmt?

Mit Ticket 19276 wurde das Automatische Schließen von Lieferscheinen so erweitert, das es wie die Funktion zum automatischen Schließen von Aufträgen agiert. Der Lieferschein wird erst geschlossen, wenn die volle Menge in Rechnung gestellt wurde.

Mit Ticket 20341 wurde diese Funktion für Aufträge jedoch angepasst und überarbeitet. Um ein einheitliches Codebild zu wahren, soll die Funktion zum schließen von Lieferscheinen so angepasst werden wie die Funktion zum schließen von Aufträgen.

Wenn man bei einer Rechnung den Button "Zahlung buchen" verwendet, kommt folgende Fehlermeldung: "do_transaction() failed - Abteilung ist notwendig für Buchung at /opt/erp/mbb/test/odyn-erp/SL/IS.pm line 895." Diese Meldung wird angezeigt, auch wenn die Rechnung eine Abteilung hat.

Da die Rechnung beim Verwenden "Zahlung buchen" nicht komplett neu gespeichert wird, soll die Prüfung auf Abteilung korrekt durchgeführt werden.

Bei der Prüfung ob mit dem Buchen einer Rechnung ein Auftrag geschlossen werden soll, werden Auftragspositionen nach verknüpften Rechnungspositionen durchsucht. Wenn die in Rechnungspositionen vorhandene Menge größer oder gleich der Menge der Auftragsposition ist, gilt sie als vollständig in Rechnung gestellt. Wenn alle Positionen eines Auftrags vollständig in Rechnung gestellt sind, wird der Auftrag mit dem Buchen der letzten Rechnung geschlossen.

Unter sehr spezifischen Umständen konnte es vorkommen, das mehr verknüpfte Positionen gefunden wurden als tatsächlich vorhanden waren. Wenn ähnlich viele Lieferschein- und Rechnungspositionen in der Datenbank vorhanden sind, ist dieses Verhalten wahrscheinlicher. Je länger das ERP in Benutzung ist, desto weniger wahrscheinlich ist dieser Fehler.

Das Fehlverhalten soll behoben werden.

Beim Einlagern von EK-Lieferscheinen kann es zu einer Fehlermeldung kommen.

Das Einlagern soll ohne Fehlermeldung möglich sein.

In ERP-Dokumenten werden Preisregeln nur noch erkannt, wenn diese die Bedingung "Teilbarkeit durch VE" enthalten.

Preisregeln sollen unabhängig von der Bedingung erkannt werden.

In den Stammdaten eines Artikels können Verbrauch und Beschaffungszeit angegeben werden. Aus diesen Werten berechnet sich ein Meldebestand. Sobald dieser Meldebestand erreicht/unterschritten wird, wird der Artikel in einer Liste geführt um eine Nachbestellung zu verursachen.

Die Beschaffungszeit wird manuell geführt, der monatliche Durchschnitts-Verbrauch soll aber regelmäßig durch das ERP bestimmt und in die Stammdaten des Artikeln eingetragen werden. Hierfür soll ein Hintergrund-Job angelegt werden, welcher diese Berechnung vornimmt. Es sollen nur Artikel mit "Disposition nach Verkauf" aktualisiert werden.

Es soll dabei Konfigurierbar sein:

• Wie oft und wann wird diese Berechnung durchgeführt, einstellbar über das Anlegen des Hintergrund-Jobs.
• Über welche Periode wird der Durchschnittsverbrauch bestimmt?

In #20380 wurde eine Bedingung implementiert die es ermöglicht eine Zahl durch die die Menge einer Position restlos teilbar sein soll anzugeben. Diese Bedingung soll umgewandelt werden zu: Restlos teilbar durch die VE in den Stammdaten des Artikels.

Aktuell wird das Versanddatum immer berechnet (Lieferdatum - Lieferdauer (in Tagen) aus den Kunden-Stammdaten) und kann nicht editiert werden. In folgenden Fällen ist eine manuelles erfassen erforderlich:

1. bei Versand von unserem externen Lager, die Lieferdauer je nach Versandweg (Paketdienst oder Spedition) variiert
2. Verschiedene Transport-Arten haben unterschiedliche Lieferdauer (Paketdienst und auch per Spedition versendet werden

Der Lieferschein zu der Lieferantenbestellung "BE103035" soll eingelagert werden. Beim Einlagern gibt es aber eine Fehlermeldung.

Das Einlagern soll ohne Fehlermeldung möglich sein.

SDBs sollen durch einen Task-Server Job an einen Artikel angehängt werden. Die Dateinamen der SDBs geben an welcher Artikel dazugehört. SDBs mit Sonderzeichen werden nicht korrekt an ihre Artikel angehängt.

Dieses Verhalten soll korrigiert werden.

Aktuell hat ein 1 SDB nur 1 Artikel. Da aber weitere Artikel (z. B. nur anderes Gebinde) das gleiche SDB haben ist es notwendig das mehrerer Artikel auf das gleiche SDB verweisen. Der Taskserver soll dies berücksichtigen und die Verweise auf mehrere Artikel erstellen. Die Verweise funktionieren wie bei allen anderen Dokumenten und Dateianhängen.

Falls für Aufträge die komplette Menge reserviert wird, werden die reservierten Artikel nicht produziert. Dennoch ist in der Produktionsübersicht der reservierte Artikel enthalten. Dabei wird nur das Erfassen vom AA angezeigt, mit Menge 0,00000.

Produktionsübersicht soll nur Auftrags-Differenz zwischen bestellt und reserviert anzeigen.

Artikel mit Änderungen oder neu erfassten Informationen im Feld Dateipfad/Zeichnung erfordern z. Z. ein manuelles Verweisen auf das SDB. Dies soll über den Taskserver automatisiert werden.

Dabei werden die existierenden SDBs durchsucht und wenn ein Eintrag im Feld Dateipfad/Zeichnung zutrifft wird ein Verweis auf dieses SDB erstellt.

Wenn man bei einer Rechnung den Button "Zahlung buchen" verwendet, kommt folgende Fehlermeldung: "do_transaction() failed - Abteilung ist notwendig für Buchung at /opt/erp/mbb/test/odyn-erp/SL/IS.pm line 895." Diese Meldung wird angezeigt, auch wenn die Rechnung eine Abteilung hat.

Da die Rechnung beim Verwenden "Zahlung buchen" nicht komplett neu gespeichert wird, soll die Prüfung auf Abteilung korrekt durchgeführt werden.

Alle Artikel, die "Grundfos" in der Artikelbeschreibung enthalten sollen wie folgt angepasst werden:

1. Prüfung, ob der Lieferant "Grundfos" als Lieferant eingetragen ist und ob der Haken "Lieferantenpreis aktualisieren" gesetzt ist

2. Falls ja soll nichts gemacht werden, falls nein soll der Lieferant hinzugefügt und er Haken gesetzt werden.

Die angefassten Artikel sollen in einer Liste gespeichert werden.

Durch das Schließen vom Auftrag/PA werden Verknüpfte PAs (PA/ML0-5. geschlossen und alle Reservierungen aufgelöst. Ein Workflow zu diese Handhabung wird in einem Folgeticket noch behandelt, aktuell ist die Vergangenheit zu bereinigen.

Aktuelle Bestände im Lagerort/Platz "Produktion/1" ohne Reservierung sind zu "Entnehmen", -mit Grund der Entnahme: "Korrektur" und -Optionaler Kommentar: "Auftrag/PA geschlossen und Reservierung aufgelöst"

Das kopieren von mehreren Positionen im PA/ML und einfügen an gewünschter Position fehlt aktuell.

Dazu sollen neue Funktion implementiert werden:

1. Mehrere Positionen können mit der Checkbox ausgewählt werden
2. Neuer Button "Kopiere Pos." neben "Mehrere Artikel hinzufügen"
3. Dialog mit Frage an welcher Position soll eingefügt werden

Falls für Aufträge die komplette Menge reserviert wird, werden die reservierten Artikel nicht produziert. Dennoch ist in der Produktionsübersicht der reservierte Artikel enthalten. Dabei wird nur das Erfassen vom AA angezeigt, mit Menge 0,00000.

Produktionsübersicht soll nur Auftrags-Differenz zwischen bestellt und reserviert anzeigen.

Retouren-Lieferscheine haben nach Einlagerung um den Faktor der Verrechnungseinheit zu viel Bestand.

Das Verhalten tritt auf wenn ein Erzeugnis in einem VK-Lieferschein eingelagert wird.

In Aufträgen kommt es vor, dass Positionen "Teilreserviert" werden. Dabei wird ein Teil der Positionsmenge aus dem Lager reserviert und ein Teil produziert. (z.B. 200kg Bestellt, 100kg aus Lager und 100kg aus Produktion).

Beim Erstellen des Soll-Lieferscheins wird diese Position in zwei Positionen aufgeteilt, eine mit der reservierten Charge aus dem Lager und eine ohne Charge (Chargenreinheit). Bei der Rückmeldung der Abfüllanweisung aus der Position sollte die LS-Position ohne Charge die Produktionscharge eingetragen bekommen.

Stattdessen wird die Position der Teilreservierung aus dem Lieferschein entfernt, nachdem die Abfüllanweisung zurückgemeldet wird,.

Teilreservierungen sollen beim Zurückmelden der Abfüllanweisung nicht aus dem Lieferschein entfernt werden.

Die Ausgabe des Prüfprotokolls soll wie folgt angepasst werden:

Im Pop-up "Dokumentation drucken" soll der Button "Prüfprotokoll drucken" durch die Buttons 
"Prüfprotokoll Elektro" und "Prüfprotokoll Mechanik" ersetzt werden.
Je nachdem, welches Prüfprotokoll gedruckt werden soll, wird das jeweilige PDF-Dokument angezeigt.

Die Protokolle sollen wie im Entwurf nachgebaut und im ERP-System implementiert werden.

Das bei Pender implementierte Feature zu Überschriftsartikeln soll für den Standard angepasst und eingebaut werden.

Um die Anzahl der offenen Aufträge zu verringern, sollen diese über einen Taskserverjob überprüft werden. Alle Aufträge, bei denen der Liefertermin in der Vergangenheit liegt, sollen per Mail an ausgewählte Email-Adressen versendet werden.

Falls ein Benutzer ein ERP-Dokument zu lange offen hat, kann es vorkommen, dass dieses Dokument geändert wurde. In diesem Fall reagiert das ERP-System und warnt den Benutzer, dass die Daten nicht mehr aktuell sind. Der Benutzer hat dann die Möglichkeit das Dokument zu speichern, das ERP-Dokument in einem neuen Tab zu öffnen oder abzubrechen. Falls das ERP-Dokument vom Benutzer gespeichert wird, werden wichtige Werte (auslagern, offen, geschlossen,…) verändert.

Diese Werte dürfen beim Neuspeichern nicht verändert werden

Bei allen Stellen an denen Dokumente in das ERP-System hochgeladen werden können, soll dies durch Drag&Drop ermöglicht werden. Diese Funktionalität liegt bereits vor, ist aber schlecht kommuniziert und etwas ungünstig zu verwenden.

Es muss das Dokument auf ein spezifisches Areal gezogen werden, um den Upload auszulösen. Diese Areal soll vergrößert werden, so das das gesamte Fenster für Drag and Drop Uploads verwendet werden kann, sobald ein Upload-Popup/Fenster geöffnet ist.

Zusätzlich soll dem Benutzer das Feature besser kommuniziert werden. Es soll an Stellen an denen Drag and Drop möglich ist, ein Text und Icon eingefügt werden welches dem Benutzer signalisiert das hier DnD verwendet werden kann

In der 'Artikelauswahl/Mehrfachtreffer' werden momentan bei Einkaufs- und Verkaufs-Dokumenten in der Spalte "Andere Treffer" unterschiedliche Daten angezeigt.

In Einkaufs- und Verkaufs-Dokumenten soll in Spalte "Andere Treffer" folgendes angezeigt werden:

• EAN des Artikels
• abweichende Artikelnummer

Lieferscheine werden automatisch geschlossen, wenn aus Ihnen eine Rechnung erstellt wurde. Bei Teilabrechnungen zu Lieferscheinen muss der Lieferschein immer wieder neu geöffnet werden, um eine Rechnung zu erstellen.

Um diesen Workflow besser zu gestalten, sollen Lieferscheine erst automatisch geschlossen werden, wenn alle Positionen in Rechnungen enthalten sind.

CSV-Importe werden über einen Background-Job im Task-Server durchgeführt.

Dabei ist es möglich, dass harte Fehler entstehen und der Background-Job fehlschlägt. Zurzeit wird dieses Verhalten dem Benutzer nicht kommuniziert. Es sieht weiterhin so aus, als würde der Import arbeiten.

Um Fehler dieser Art dem Benutzer ersichtlich zu machen, ohne den Job-Verlauf im Task-Server zu verwenden, soll eine Fehleranzeige für CSV-Importe angelegt werden. Wenn der Background-Job fehlschlägt, soll die Fehlermeldung automatisch ermittelt und angezeigt werden.

Um für den Benutzer die Ermittlung von Rabatt- und Preisen durchsichtig zu gestalten, wird die Preisquelle in einem Button angezeigt. Leider ist die Rabattquelle erst in dem Fenster sichtbar das mit dem Button geöffnet wird.

Die aktive Rabattquelle soll genau wie die aktive Preisquelle direkt beim Öffnen des Dokuments ersichtlich sein. So eine Anzeige ist bereits in der Auftragsschnellerfassung enthalten und kann von dort portiert werden.

Der Button soll nach wie vor das Fenster zur Preisquellenauswahl öffnen.

Das Fälligkeitsdatum von Rechnungen wird durch die Zahlungsbedingung bestimmt. Fällt das errechnete Datum auf ein Wochenende, wird der nächste Montag als Fälligkeitsdatum gesetzt. Auf Verkaufsseite stellt das kein Problem dar, im Einkauf werden Rechnungen dadurch potenziell zu spät bezahlt.

Im Einkauf soll bei der Berechnung des Fälligkeitsdatums, falls das errechnete Datum auf ein Wochenende fällt, der vorhergehende Freitag und nicht der folgende Montag gesetzt werden.

Die Anleitung "Mahnungen" aus der öffentlichen Wiki, soll über einen Hilfe-Button in der Maske von "Mahnungen konfigurieren" erreichbar sein. In diesem Zusammenhang kann die Option "PDF an E-Mail anhängen" aus der Konfiguration entfernt werden, da diese keine Funktion mehr hat.

Wenn der Tab "Verknüpfte Belege" geöffnet wird, werden alle verknüpften Objekte sortiert und (wenn eine Liste dafür definiert ist) angezeigt. Dabei wird zuerst auf eine explizite Sortierfunktion zugegriffen und sollte diese nicht existeren nach "Datum" sortiert. Es gibt aber immer wieder Objekte die über Verknüpfungen verknüpft werden aber kein Datum und keine Sortierfunktion besitzen. In diesen Fällen wird in den Verknüpften Belegen eine Fehlermeldung angezeigt, sobald 2 oder mehr dieser Objekte verknüpft sind.

Es soll eine weitere Sortierung eingeführt werden wenn weder Datum noch Sortierfunktion vorhanden sind. Dabei soll nach der internen ID sortiert werden die jedes Objekt besitzen sollte. Wenn sogar diese Sortierung fehlschlägt soll keine Fehlermeldung entstehen sondern einfach nicht sortiert werden. Für den Benutzer sollte keine Änderung ersichtlich sein.

Rechnungen können eine 'deliverycustomerid' enthalten. Darin wird wie bei Aufträgen und Lieferscheinen der Unterkunde gespeichert. Anders als bei Aufträgen und Lieferscheinen ist diese Beziehung jedoch nicht in der Datenbank hinterlegt und es wäre z.B. möglich in der deliverycustomerid auf einen Kunden zu verweisen der nicht existiert.

Die Datenbankbeziehung soll in Rechnungen genau wie in Aufträgen und Lieferscheinen funktionieren.

Zur Zeit ist das automatische Schließen von Aufträgen und Lieferscheinen eine eigene Aktion die in Buchungsvorgängen als getrennt aufgerufen wird. Das kann dazu führen das einige Aktionen Rechnungen erfassen bzw. buchen, aber keine verknüpften Aufträge schließen wie das über den Workflow passieren würde.

Das schließen von Aufträgen sollte immer am Ende des Buchungsvorgangs geschehen. Es sollte nicht möglich sein, eine Rechnung zu buchen ohne das die Prüfung zum schließen von Aufträgen und Lieferscheinen durchzuführen.

Zur Zeit wird in der Logik des automatischen Schließen von Aufträgen nicht auf stornierte Rechnungen geachtet. Wird z. B. die Gesamtmenge des Auftrags in Rechnung gestellt und diese dann Storniert, bleibt der Auftrag geschlossen. Sehr häufig folgt nach der Stornorechnung gleich die korrigierte Rechnung, wodurch der Auftrag geschlossen bleiben kann. Auch das erneute öffnen vom Auftrag ist für den User kein nennenswerter Aufwand.

Bei Rechnungstellung von Teilmengen sorgt eine Verbesserung in der Logik für Entlastung beim User, z. B. : Auftrag mit 2 Positionen, nur die erste Position wird in Rechnung gestellt und diese dann storniert. Nach der Rechnungstellung der zweite Position, wird der Auftrag geschlossen obwohl nicht "alles abgerechnet" ist.

Stornierte Rechnungen sollen für das automatische Schließen von Aufträgen nicht einbezogen werden, so haben bei Rechnungstellung der Gesamtmenge und Teilmenge die Aufträge den richtigen Status.

Wenn eine Rechnung Storniert wird, soll die gleiche Logik verwendet werden um betroffene Aufträge wieder zu öffnen.

Ebenso sollen flash-Meldungen eingebaut werden die über geöffnete und geschlossene Aufträge informieren.

Im ERP wird pro Artikel gespeichert, wie groß aktuell der gesamte und der reservierte Bestand im Lager ist. Dadurch können diese Werte bei Bedarf einfach aus der Datenbank gelesen werden, anstatt dass sie immer aus den Lagerbeständen berechnet werden müssen. Es kann vorkommen, dass diese Werte am Artikel falsch gespeichert werden und daher nicht dem tatsächlichen Lagerbestand entsprechen.

Es soll dafür gesorgt werden, dass immer die korrekten Bestände an Artikeln gespeichert werden.

Beim Auflösen von Einkaufsgebinden wird in manchen Fällen durch einen Fehler verhindert, wenn die Einheit von Erzeugnis und Bestandteil voneinander abweichen.

Es soll möglich sein, Einkaufsgebinde einzulagern, auch wenn ein Bestandteil eine unterschiedliche Einheit als das Erzeugnis hat.

Artikel aktualisieren ist ein Feature, mit dem Positionen mit den neusten Werten für Preise etc. befüllt werden können. Es sollen nur die Felder befüllt werden, nicht das gespeicherte Dokument angepasst werden.

In der Auftragsschnellerfassung und Produkionsaufträgen ist dieses Verhalten abweichend: "Artikel aktualisieren" speichert das Dokument wie es gerade vorliegt.

Um Fehler zu vermeiden soll das Verhalten von "Artikel aktualisieren" angepasst werden, so das nicht mehr gespeichert wird.

In dem Bericht "Lagerbestand" funktioniert der Filter "Warengruppe" nicht, die getroffene Auswahl wird nicht übernommen.

Der Filter soll im Bericht funktionieren.

Beim Aktualisieren von Artikeln in der Auftrags-Schnellerfassung und in Produktionsaufträgen wird das Dokument gespeichert. Dieses Verhalten ist nicht erwünscht. In der Schnellerfassung wurde der Fehler bereits behoben und muss nun auch in Produktionsaufträgen abgeändert werden.

Zur Zeit können über "Artikel aktualisieren" keine Benutzerdefinierte Variablen aktualisiert werden. Die BDV sollen genau wie andere Artikelwerte mit "Artikel aktualisieren" aktualisiert werden können. Außerdem soll nach erfolgreicher Aktualisierung eine Flash-Info ausgegeben werden: "Artikel wurden erfolgreich aktualisiert."

Um Änderungen an den Rezepten nicht nur im ERP-System, sondern auch in Chemges richtig zu führen, soll die
Überführung der Datensätze von ERP-System zu Chemges ermöglicht werden.

Dabei sollen die Rezepte beim Speichern der Baukastenliste im ERP-System automatisch exportiert und Chemges
zum Import bereitgestellt werden.

Anwendung:
Der Benutzer bekommt die Datei aus dem ERP-System automatisch zum Download angeboten.
Im Browser des Benutzers wird eingestellt, dass "ascr-Dateien" mit einem VBS-Skript automatisch geöffnet werden sollen.
Dieses Skript sorgt für den Import in Chemges und das Löschen der heruntergeladenen Datei beim Benutzer.

Im Großen und Ganzen genauso wie bei dem Etikettendruck.

An Kunden wird eine Preisliste mit allen Artikeln und deren Versandeinheiten geschickt. Anhand dieser Liste bestellen die Kunden, die Artikel in den Versandeinheiten. Bei einer Bestellung bekommt der Kunde 5 % Rabatt, wenn er in Versandeinheiten bestellt. Dieser Rabatt entfällt, aber wenn er in zusätzlich zu den Versandeinheiten noch eine Packung eines Artikels mitbestellt.

Hintergrund: Die Lagermitarbeiter müssen bei Bestellung von Versandeinheiten nicht umpacken. Sie können die Ware einfach in den Versandeinheit lassen und die Ware weiterverschicken. Bei einer Bestellung, in der zusätzliche Packungen enthalten sind, müssen die Mitarbeiter umpacken und dadurch entfällt der Rabatt.

Es werden Preisregeln mit den entsprechenden Versandeinheiten (VE) angelegt. Dabei soll die Menge restlos mit der VE teilbar sein. Ist dies der Fall, soll ein Rabatt von 5 % hinzugefügt werden. Dieser Rabatt soll auf bereits existierende Rabatte draufgerechnet werden. Außerdem soll es ein Eintrag unter der Preisquelle angezeigt werden (Preisquelle = Versandeinheit; Rabatt = 5 %)

Das Stornieren von DHL Labels über das ERP-System soll ermöglicht werden. Dafür soll ein weiterer Button zu dem Dropdown "mehr…" hinzugefügt werden.

Früher wurden Kunden mit einer Steuerzone gespeichert, diese wird beim Importieren über EDI in Aufträgen gesetzt.

Inzwischen wird die Steuerzone jedoch dynamisch bestimmt, anhand des Landes des Kunden und der Firmierung im Auftrag.

Sollte die Steuerzone fehlen schlägt der Import fehl. Es soll statdessen aus der Hauptfimierung und dem Kunden/Lieferanten die Steuerzone bestimmt werden wenn sie fehlt

Wenn in den Artikelstammdaten gleichzeitig eine oder mehrere Zeilen unter Exklusiv für foglende Lieferanten geändert werden und eine oder mehrere neue Zeilen hinzugefügt werden, werden die Änderungen verworfen und nur die neuen Zeilen hinzugefügt.

Es soll möglich sein, gleichzeitig Änderungen vorzunehmen und neue Zeilen hinzuzufügen.

Wenn in einer Dialogbuchung ein Steuerschlüssel "0" gewählt und das Dokument erneuert wird, wird die Auswahl nicht immer übernommen, sondern auf die oberste Option umgelegt.

Nach Erneuern sollen die gesetzten Steuerschlüssel nicht mehr verändert werden.

Beim Verwenden des Filters "Lager" im Bericht "Lagerbuchungen" kommt es zu folgender Fehlermeldung: "DBD::Pg::st execute failed: ERROR: missing FROM-clause entry for table "w2" LINE 9: WHERE (w1.id = $1 OR w2.id = $2. AND i1.qty < 0 ^ at /opt/erp/dtw/test/odyn-erp/SL/DBUtils.pm line 148."

Der Bericht soll ohne Fehlermeldung verwendet werden können.

Aufträge werden automatisch geschlossen, obwohl die Positionen nicht vollständig in Rechnung gestellt sind.

Aufträge sollen erst geschlossen werden, wenn sie voll in Rechnung gestellt wurden.

Beim Zusammenführen von mehreren Lieferscheinen zu einer Rechnung, wird folgende Fehlermeldung angezeigt: "YAML::XS Error: bad tag found for scalar: 'tag:yaml.org,2002:perl/code' at /opt/erp/ctq/test/odyn-erp/SL/MoreCommon.pm line 56."

Das Zusammenführen soll ohne Fehlermeldung durchgeführt werden.

Analyse: Das Problem kann nicht auf Ubuntu 20.04 und Ubuntu 22.04 nachgestellt werden. Vermutlich wurde das Paket zum Packen und entpacken von YAML Dateien für diese Versionen aktualisiert und nicht mehr für ältere. Fehler tritt auch nicht auf der Debian Version auf, die Umetec verwendet Ein Upgrade der Ubuntu Distribution auf Ubuntu 20.04 oder 22.04 würde den Fehler beheben.

Das automatische Schließen von Aufträgen ist zur Zeit ein großer Block an Anweisungen, die nacheinander abgearbeitet werden. Dabei ist es nicht möglich einzelne Teile des Vorgangs getrennt auszuführen, es ist z.B. nicht möglich nur zu Prüfen welche Aufträge geschlossen werden würden sollte eine bestimmte Rechnung gebucht werden.

Die einzelnen Schritte des Vorgangs sollen getrennt werden um außerhalb des Buchungsvorganges auf die gleichen Funktionen zugriff zu haben.

Zusätzlich soll ein Skript geschrieben werden welches Aufträge findet die geschlossen sind, obwohl sie nicht automatisch geschlossen wurden zur Fehlerkontrolle.

Die Produktion soll um folgende Funktionen erweitert werden:

• Produktionsort mit Produktionslager soll an zentraler Stelle definiert werden können
• Pro Produktionsauftrag soll ersichtlich welche Baugruppe/Unter-Erzeugnis fertig gestellt ist (Produktions-Fortschritt)
• Fertige Baugruppen/Unter-Erzeugnis sollen eingelagert und deren Bestandteile ausgelagert werden (Bestands-Fortschritt)

In der neuen Produktionsimplementierung von MBB werden Produktionsaufträge für einzelne Positionen erstellt.

Leider war das früher nicht der Fall, so dass nun Produktionsaufträge existieren bei denen die Information fehlt, welche Position hier relevant ist.

Es soll eine Funktionalität eingefügt werden, nachträglich PAs mit einer Auftragsposition zu verknüpfen.

Folgende Änderungen werden durchgeführt:

1. Wenn ein PA ohne Positionsverknüpfung geöffnet wird, wird ein neuer Button angezeigt. Dieser öffnet einen Dialog der die Positionen aus dem Verknüpften Auftrag anzeigt
2. MLs sollen den gleichen Button enthalten wie in 1. beschrieben
3. ML5 kann nur mit Positionsverknüpfung produziert werden, wenn diese nicht vorhanden ist wird der Button ausgegraut

Wenn in einen Artikel im Reiter "Kundenspezifisch" ein Kunde hinzugefügt wird, wird automatisch die Checkbox "Exklusiv für folgende Kunden" angewählt. Diese lässt sich nicht mehr abwählen. Dadurch können die Einträge für Kunden nicht mehr entfernt werden. "Exklusiv für folgende Kunden" soll wieder abwählbar sein und die Liste an kundenspezifischen Informationen soll leer gespeichert werden können.

Beim Öffnen der Verknüpfte Belge von Aufträgen wird folgende Fehlermeldung angezeigt: "Can't locate object method "date" via package "SL::DB::ExternalDataExchange" at /usr/local/share/perl/5.30.0/Rose/DB/Object.pm line 1657. "

Die verknüpften Belege des Auftrags sollen ohne Fehlermeldung geöffnet werden können.

Das Speichern von Aufträgen mit Positionsmenge 0 wird im Moment verhindert. Um den Workflow von Abrufaufträgen durchzuführen, ist es nötig, abgeschlossene Aufträge mit der Positionsmenge 0 speichern zu können.

Aufträge mit Positionsmenge 0 sollen gespeichert werden können.

Es kommt regelmäßig vor, dass Änderungen am Webserver durchgeführt werden, beim Benutzer aber weiterhin der gecachte alte Inhalt dargestellt wird. Es soll eine Möglichkeit gefunden werden, das Löschen oder Aktualisieren des Cache serverseitig zu steuern.

Die Funktion "Artikel aktualisieren" ist in allen ERP-Dokumenten verfügbar, nur in Produktionsaufträgen fehlt diese. Zur Vereinheitlichung und zur Massenaktualisierung von Artikeln in Produktionsaufträgen, wird die Funktion "Artikel aktualisieren" auch in Produktionsaufträgen eingebaut.

Um den Benutzern den Zugang zu den FAQs zu erleichtern, sollen diese über die Startseite als auch über den Menüpunkt Programm verknüpft sein.

Wird momentan eine Rechnung gedruckt, dessen Verkäufer gelöscht wurde, wird auf der Rechnung keine E-Mail des Verkäufers ausgegeben. Wird eine Rechnung allerdings über den Massendruck von Rechnungen gedruckt, wird auch die E-Mail eines gelöschten Verkäufers ausgegeben.

Der Massendruck von Rechnungen, soll nun so angepasst werden, dass die E-Mail des Verkäufers nur ausgegeben wird, wenn dieser nicht gelöscht wurde.

Wenn bei der Auswahl von Lieferscheinen ein bereits geschlossener Lieferschein ausgewählt wird, wird eine harte Fehlermeldung ausgeworfen. Diese soll in eine Flash-Meldung umgewandelt werden.

Die Fehlermeldungen für unterschiedliche Kunden/Lieferanten, unterschiedliche Firmierungen und keine ausgewählten Lieferscheine sollen ebenfalls zu Flash-Meldungen umgewandelt werden.

Stornorechnungen im Einkauf werden im Bericht zu EK-Rechnungen aktuell als Typ "Gutschrift (G)" dargestellt. Dadurch können diese nicht von tatsächlichen Gutschriften unterschieden werden.

EK-Stornos sollen analog zum Verkauf als Typ Storno (S) dargestellt werden.

Der Verkaufsbericht soll um die Option "Stadt" erweitert werden. Falls diese aktiviert wird, soll die Stadt des Kunden in den Bericht mit aufgenommen werden.

Wenn in den Berichten unter "Lager" (Lagerbuchungen, Lagerbestand) nach Artikelnummer oder Charge gesucht wird, werden immer auch Ergebnisse angezeigt, die den gesuchten Text enthalten, aber nicht exakt mit ihm übereinstimmen.

Wenn im Feld als erstes Zeichen ein Gleichheitszeichen "=" eingegeben wird, sollen nur exakte Treffer für die Eingabe gesucht werden. Dieses Verhalten soll durch einen Hilfetext erklärt werden.

In dem Suchformular für den Auftrag kann nach dem Feld "Versandort" gesucht und gefiltert werden. Diese Funktion soll auch in den Suchformularen für Lieferscheine und Rechnungen implementiert werden.

Wenn ein Bestandteil in der Baukastenliste eines Artikels verschoben wird, werden alle Änderungen in den Positionen dokumentiert. Diese sind zur Zeit nicht sortiert und somit schwer zu lesen.

Die Historieneinträge sollen nach alter Position sortiert sein. Außerdem sollen sie in der Reihenfolge: Artikel gelöscht/hinzugefügt -> Verschiebungen -> Mengenänderungen angelegt werden.

Damit ist auf einen Blick die Änderung der Baukastenliste sichtbar.

In den Artikelstammdaten soll hinter das Feld "Beschaffungszeit/ Produktionszeit" die Einheit "in Tagen" ausgegeben werden. Es soll überall "Beschaffungszeit/Produktionszeit (in Tagen)" angegeben werden.

Um vorhandenen Bestand ohne Charge/MHD (Mindesthaltbarkeitsdatum) diese nachträglich zu vergeben, oder vorhandene zu korrigieren, kann die 'Umlagerung' benutzt werden.

Wenn in der Mandantenkonfig "Mindesthaltbarkeit" angeschalten ist, können Lagerbestände/Buchungen ebenfalls mit einem MHD versehen werden. Aktuell wird das Feld MHD bei der Umlagerung nicht angezeigt und somit nicht nutzbar.

Bei Umlagern soll es auch möglich sein ein neues MHD einzugeben. Dabei soll sich das Feature wie bei der Chargennummer verhalten.

In der Auftragsübersicht zu einem Auftrag wird eine negative abzurechnende Summe sowie ein nicht nachvollziehbarer Abgerechneter Betrag dargestellt. Es soll herausgefunden werden, wie die Beträge zustande kommen. Der Kunde erwartet bei abgerechneter Betrag die Summe der Rechnungen .

Insbesondere beim Anzeigen der ersten Seite, kann das Laden des Berichts "Lagerbuchungen" viel Zeit in Anspruch nehmen, da im Hintergrund unnötige Daten geladen werden.

Der Bericht soll so optimiert werden, dass eine Seiten innerhalb weniger Sekunden geladen wird.

Beim Löschen eines Dokuments in den Dateianhängen wird folgende Meldung angezeigt: "Möchten Sie die ausgewählten Verweise löschen?"

Die Meldung soll wie folgt angepasst werden:

Wenn nur Verweise ausgewählt sind: "Möchten Sie die ausgewählten Verweise löschen?"

Wenn keine Verweise ausgewählt sind: "Möchten Sie die ausgewählten Dateien löschen?".

Wenn Verweise und Dateien ausgewählt sind: "Möchten Sie die ausgewählten Verweise und Dateien löschen?"

Die Aktion "als neu speichern" hat nicht immer einen Eintrag in der Historie (mit Quelldokument in Spalte 1: Erstellt aus).

Es soll herausgefunden werden wann dies unvollständig ist und behoben werden.

Bei Verwendung der Funktion "Als neu speichern" in ERP-Dokumente wird nicht darauf hingewiesen, dass die Zahlungs/- und Lieferbedingungen nur in das neue ERP-Dokument übernommen werden, wenn man die Option "Formularfelder" verwendet.

Die Beschriftung der Checkbox soll zu "Formularfelder kopieren (Vorgangsbezeichnung, Liefer/Zahlungsbedingungen, etc.)" angepasst werdne.

Die beiden folgenden Aktionen können sich gegenseitig blockieren, wenn sie gleichzeitig ausgeführt werden und die erste Aktion kurz vor der zweiten beginnt:

• Eine neue Rechnung mit leerer Rechnungsnummer speichern, die aus einem Auftrag erstellt wurde, wodurch der Auftrag geschlossen wird
• Einen neuen Auftrag mit leerer Auftragsnummer speichern Beide Aktionen müssen dabei ihre jeweilige Nummer aus der selben Quelle beziehen (selbe Firmierung oder aus Mandantenkonfiguration). Bei der Ermittlung der Auftragsnummer und dem Schließen des Auftrags blockieren sich die beiden Aktionen gegenseitig, wodurch eine der beiden zur Konfliktlösung automatisch von der Datenbank beendet wird.

Die beiden Aktionen sollen ohne Konflikte parallel ausgeführt werden können.

Wenn eine Lieferinformation mit leerem Standardtext erfasst wird, erscheint eine Fehlermeldung. Der Fehler erscheint auch, wenn die Liste der Lieferinformationen erneut geöffnet wird.

Das erfassen von Lieferinformationen ohne Standardtext soll verhindert werden.

Aufträge werden automatisch geschlossen, wenn Rechnungen mit der vollständigen Auftragsmenge erstellt und gebucht wurden. Bei dieser Berechnung werden alle Mengen in die "Basiseinheit" des Artikels umgerechnet, z.B. Gramm zu Kilogramm. Es kann passieren das hierbei besonders kleine Mengen verloren gehen und die Auftragsmenge nicht als vollständig in Rechnung gestellt angesehen wird.

Die Mengen sollen korrekt bestimmt werden.

Wenn in einer Rechnung der Kunde/Lieferant gewechselt wird, wird die Steuerzone nicht aktualisiert. Dies kann zu falschen Angaben der Steuer führen.

Beim Kunden-/Lieferantenwechsel in einer Rechnung soll die Steuerzone anhand des Landes aktualisiert werden.

Benutzerdefinierten Variablen für Aufträge können so konfiguriert werden, dass diese in Berichten angezeigt und durchsucht werden können. Die Aktivierung dieser Konfigurationen hat derzeit keine Auswirkung.

Die Optionen "Durchsuchbar", "In Berichten anzeigbar" und "In Berichten standardmäßig enthalten" sollen funktionieren, wenn diese aktiviert sind.

Ist im Bericht "Prüfung der Zählung" in der Inventuraufnahme der Spezialfall "Über-reserviert" ausgewählt, werden nur Einträge angezeigt, für die im ERP mehr Menge reserviert wurde, als in der Zählung erfasst sind. In der Spalte "Über-reserviert" werden Links zu den ERP-Dokumenten aufgelistet, die für diese Über-Reservierung verantwortlich sind. Im Falle von Produktionsaufträgen werden die Links zur Zeit nicht angezeigt.

Es sollen auch die Links zu Produktionsaufträgen aufgelistet werden, die für Über-Reservierungen sorgen.

Beim Speichern des Lieferscheins "L024474" kommt folgende Fehlermeldung: "dotransaction() failed - Can't call method "markordersifdelivered" on an undefined value at bin/mozilla/do.pl line 2918." Das Speichern wird trotz Fehlermeldung durchgeführt.

Die Fehlermeldung soll nicht mehr ausgegeben werden.

Bei der Verwendung von mehr als zwei Nachkommastellen im Einkauf kommt es zu ungewollten Rundungen des Preises, wenn die Menge des Artikels geändert wird und diese mit Enter im Megenfeld bestätigt wird. Beim Einfügen des Artikels werden die korrekten Preise noch gesetzt. Das Verhalten tritt nicht auf, wenn die neue Menge mit "Erneuern" bestätigt wird.

Sind mehr als 2 Nachkommastellen in der Mandantenkonfiguration hinterlegt, soll die Rundung des EK-Preises auch nur bis zur eingestellten Nachkommastelle erfolgen.

Beim Ausdruck der Lieferscheine sollen die Gewichtsangaben angepasst werden. Diese sollen wie folgt ausgegeben werden:

Positionstabelle: Ausgabe Gewicht bei nicht kg-Artikeln = Latex-Variable: lineweight

Unter die Positionstabelle: Bruttogewicht = Latex-Variable: totalweight Nettogewicht = Latex-Variable: nettoweight

Bei der Mehrfachauswahl von Artikeln wird die Verrechnungseinheit des ersten Artikels in das ERP-Dokument eingetragen, obwohl dieser nicht ausgewählt und hinzugefügt wurde.

Wird die Mehrfachauswahl von Artikeln verwendet, soll die VE des ausgewählten Artikels in das ERP-Dokument übernommen werden.

Im Intrastat-Bericht werden alle Werte ohne Nachkommastellen angezeigt. Falls in der Spalte "Besondere Maßeinheit" Werte enthalten sind, werden diese aber mit Nachkommastellen angezeigt. Dies führt beim Öffnen der exportierten CSV-Datei des Intrastat-Bericht zu Problemen. Beim Exportieren des Intrastat-Bericht wird dieser als CSV-Datei mit "Komma" als Zeichentrennung erstellt. Durch das Komma in den Werten der Spalte "Besondere Maßeinheit" werden die Daten verschoben und müssen händisch in der Datei angepasst werden.

Die Werte in der Spalte "Besondere Maßeinheit" sollen ohne Nachkommastellen ausgegeben und exportiert werden.

Die Preisregeln sollen um die Option Preisgruppen erweitert werden. Dabei sollen die Preisgruppen als Bedingung verwendet werden können. Falls es Preisgruppen gibt, sollen diese unter der Bedingung "Warengruppen" angezeigt werden.

Bei der Berechnung der Produktionszeiten werden nur die Aufträge in der aktuellen Ansicht bzw. Seite, falls Paginierung aktiv ist, berücksichtigt.

Bei der Berechnung der Zeiten soll die Paginierung ignoriert und die Daten des gesamten Berichtes als Basis für die Berechnung verwendet werden.

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.

Beim Kundenwechsel in der Auftragsschnellerfassung kann es unter Umständen zu folgenden Fehlermeldungen kommen: Can't call method "getactivetaxkey" on an undefined value at /opt/prod/odyn-erp/SL/DB/Part.pm line 455. Can't call method "infoaspopup" on an undefined value at /opt/prod/odyn-erp/SL/Controller/Order.pm line 506.

Der Wechsel der Kunden in der Maske der Auftragsschnellerfassung soll ohne Fehler möglich sein.

Bei Nutzung des Verkaufsberichts mit Filter auf "Steuerzone" werden manche Rechnungen trotz gesetzter Steuerzone nicht aufgelistet. Wenn keine Steuerzone angegeben wird, werden die Daten der fehlenden Rechnungen angezeigt.

Der Verkaufsbericht soll die Daten der Rechnungen anzeigen, wenn die richtige Steuerzone ausgewählt wird.

Beim Erstellen eines Lieferantenauftrages aus einem Abrufauftrag wird nach dem Speichern des Lieferantenauftrages folgende Fehlermeldung angezeigt:

"dotransaction() failed - source order for call order has wrong order mode callorder at /opt/prod/odyn-erp/SL/OE.pm line 781."

Es kommt ab und zu vor, dass die hinterlegten kundenspezifischen Einträge aus den Artikelstammdaten gelöscht werden. In der Historie der betroffenen Artikel ist kein Hinweis auf eine Änderung ersichtlich.

Es soll herausgefunden werden, wie die Einträge gelöscht wurden. Das Verhalten soll in Zukunft verhindert werden.

Beim Fertigen von Erzeugnissen über das Lager (Lager/Lager…/Lagerbestände/Erzeugnis fertigen) kommt eine Fehlermeldung, ein manuelles Fertigen ist nicht möglich.

Erzeugnisse sollen auch über das Lager manuell gefertigt werden können.

Der Fokus ist nach Hinzufügen eines Bestandteils in die Baukastenliste nicht mehr im Feld Beschreibung, sondern in dem Feld Menge.

Der Fokus soll an das Ende der Artikelbeschreibung springen.

Der Verkaufspreis von Artikel in Rechnungen zeigt zu viele Nachkommastellen im Reiter Preisinformation der Artikelstammdaten.

Die Nachkommastellen sollen richtig dargestellt werden.

Wird das Einlagern von Einkaufslieferscheinen von vor dem 11.11.2015 storniert, werden keine Lagerbuchungen erzeugt. Dadurch entstehen falsche Bestände. Ebenso Tritt der Fehler bei einigen Verkaufslieferscheinen auf.

Das Stornieren von Einlagerung und Auslagerung bei alten Lieferscheinen soll korrekt funktionieren.

Die fehlerhaften DB-Einträge sollen korrigiert werden.

Beim Hinzufügen eines Artikels in der Auftragsschnellerfassungsmaske wird der Preisfaktor nicht berücksichtigt.

Der Preisfaktor soll beim Hinzufügen von Artikeln berücksichtigt werden.

Das Konto von gebuchten Zahlungen wird falsch dargestellt, wenn in der Mandankonfiguration die Änderbarkeit von Zahlungen auf immer eingestellt wird.

Es soll immer das Konto angezeigt werden, auf dem die Zahlung gebucht wurde.

Grundsätzlich wird der Positionsrabatt in Rechnungen vom Wert in der Spalte "Preis" abgezogen und das Ergebnis in die Spalte "Gesamt" eingetragen. Beim Erfassen einer Gutschrift aus einer Rechnung wird der Gesamtbetrag einer Position in das Feld "Preis" übernommen. Falls ein Positionsrabatt verwendet wird, wird dieser in der Gutschrift erneut abgezogen und somit ein falscher Wert berechnet.

Bei Verwendung von Gutschriften sollen die gleichen Preise (inkl. Rabatt) wie in der Rechnung verwendet werden.

Wurde bereits eine temporäre Lieferadresse gesetzt und die Rechnung gebucht, lässt sich die temporäre Lieferadresse nicht mehr ändern. Die neu eingegebene Adresse wird beim Buchen der Rechnung verworfen. So ist es nicht möglich, die temporäre Lieferadresse zu ändern. Es soll ermöglicht werden, die temporäre Lieferadresse auch nach dem Buchen ändern zu können.

Wird der Bericht zu Artikelstammdaten mit der Spalte EK-Preis ausgeführt, steht bei allen Artikeln ein EK-Preis von 0,00€.

Der Artikelbericht soll wieder die korrekten EK-Preise anzeigen.

Um die Auslastung der Fertigung und die Lieferzeiten besser einschätzen zu können, soll im Lieferplan-Bericht (Verkauf/Lieferplan) eine neue Funktion "Zeiten berechnen" implementiert werden.

Nachdem der Lieferplan erstellt wurde, kann der Benutzer auf "mehr/Zeiten berechnen" klicken. Dabei werden dem Benutzer die Fertigungszeiten aller Arbeitsschritte aufsummiert angezeigt. Es werden nur Artikel aus offenen Aufträgen verwendet, welche noch nicht geliefert wurden.

Arbeitsschritte (angelegte Dienstleistungen): D1, D2, D3, F1, F2, F3, F4, FS und S1 Berechnung der Fertigungszeiten:

1. Tkalk = Anzahl Artikel * TS + TA
2. Treal = Anzahl Artikel * TSr + TAr

Die Werte TS, TA, TSr und TAr sind aus der Kalkulation des jeweiligen Erzeugnisses zu verwenden.

Es gibt das Problem, dass sobald ein Lieferschein erstellt wurde, ein Etikettennachdruck aus dem Auftrag nicht mehr möglich ist.

Etiketten sollen immer gedruckt werden können, egal welcher Status der Auftrag hat.

Wird beim Buchen einer Rechnung ein Folgeauftrag erstellt, wird das Merkmal "Lieferschein(e) mit kompletter Menge erstellt" an den neuen Auftrag übergeben, obwohl dieser keinen Lieferschein verknüpft hat.

Beim Erstellen eines Folgeauftrages soll das Merkmale "Lieferschein(e) mit kompletter Menge erstellt" nicht gesetzt werden.

Beim Drucken von Rechnungen über die Massenerstellung werden Dokumenteninformationen nicht ausgegeben. Dies kann dazuführen, dass die Rechnungsnummer in die ausgegebene Lieferadresse verschoben wird. Wird die Rechnung im ERP-Dokument gedruckt, werden die Dokumenteninformationen ausgegeben.

Fehlende Informationen:

• Lieferscheindatum
• Bestelldatum des Kunden
• E-Mail-Adresse des Verkäufers

Der Ausdruck der Rechnung soll in der Massenerstellung und im ERP-Dokument gleich aussehen.

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.

Wird ein bereits ausgelagerter Lieferschein gedruckt, erscheint die folgende Fehlermeldung:
"Kein Konto gefunden für Position 1".
Zusätzlich erscheint eine Flash-Warnung, dass der Lieferschein bereits geliefert wurde und Änderungen verworfen wurden. Der Benutzer erhält aber keine PDF.

Drucken von bereits ausgelagerten Lieferscheinen soll ohne Fehlermeldung möglich sein.

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

Bei wiederkehrenden Rechnungen sollen die HTML E-Mails korrekt formatiert sein.

Außerdem sind in der Liste der Textvorlagen die Beschreibungen "Verkauf: Rechnungsübersicht" und "Verkauf: Wiederkehrende Rechnungen" vertauscht: Die Beschreibungen sollen wieder an den richtigen Plätzen angezeigt werden.

Momentan ist es im Bericht Lieferplan unter „Verkauf/Lieferplan“ nicht möglich nach der Bestellnummer des Kunden zu filtern.

Es soll ermöglicht werden, nach der Bestellnummer des Kunden zu filtern. Außerdem sollte es möglich sein, über eine Checkbox die Spalte „Bestellnummer des Kunden“ in den Bericht aufzunehmen.

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

Das Benutzen von Firmierungen ist bisher optional. Wenn es keine Firmierung gibt, werden die Firmeneinstellungen aus der Mandatenkonfig verwendet.

Die Firmeneinstellungen sollen nur noch über Firmierungen festgelegt werden und nicht mehr über die Mandantenkonfig. Daher muss immer mindestens eine Firmierung angelegt sein.

Umzusetzen ist:

• Für bestehende ERP-Installationen, die bisher keine Firmierungen benutzen, muss eine Firmierung angelegt und die Einstellungen aus der Mandatenkonfig dorthin umgezogen werden.
• Bisher werden Auswahlfelder für Firmierungen immer angezeigt sobald Firmierungen existieren. Diese sollen nur noch angezeigt werden, wenn es mehr als eine Firmierung gibt.
• Die Steuernummer wird bisher in Firmierungen über ein Freitextfeld eingetragen. Hier soll das Feature aus der Mandatenkonfig zur Veränderung der UStVa Einstellungen übernommen werden.
• Die einzelnen Kategorien in einer Firmierung sollten in unterschiedlichen Reitern angezeigt werden statt untereinander auf der selben Seite.

Branches erstellen für Releases nach 22.11 (Bugfixes, Kundenspezifisches)

Bisher werden Steuerkonten für jede Kombination von Buchungsgruppe und Steuerzone festgelegt. Um Firmierungen mit Sitz in verschiedenen Ländern zu unterstützen, sollen die Länder in der Konfiguration der Steuerkonten mit einbezogen werden, sodass ein Steuerkonto pro Kombination Buchungsgruppe-Steuerzone-Land vergeben werden kann.

In den Buchungsgruppen und Steuerzonen soll zu diesem Zweck für jedes Land aus den Firmierungen eine eigene Konfiguration ermöglicht werden.

Um die Bedienung weiter zu vereinfachen, soll die Steuerzone in ERP-Dokumenten automatisch vorausgewählt werden. Dazu soll pro Steuerzone eine Bedingung festgelegt werden können, unter der die Steuerzone ausgewählt werden soll. Folgende Bedingungen sollen zur Auswahl stehen:

Inland: Land des Kunden = Land der Firmierung EU mit USt-ID Nummer: Land des Kunden ≠ Land der Firmierung, aber beide sind in der EU und beim Kunden ist eine USt-ID hinterlegt EU ohne USt-ID Nummer: Wie zuvor, aber Kunde hat keine USt-ID Außerhalb EU: Land des Kunden oder der Firmierung ist nicht in der EU

Folgende Änderungen sind bei Firmierungen erforderlich: Aktuell kann nicht eine zweite Firmierung mit identischem Firmennamen erfasst werden. Wenn gleiche Firma mit 2x USt.-ID-NR. angelegt werden soll ist dies hinderlich.

1. Prüfung von gleicher Firmenname auf gleiche Abkürzung ändern
2. "Abkürzung" der Firmierung umbenennen in "Firmierungsname"
3. In ERP-Dokumenten soll Firmierung statt Firmenname im Auswahlfeldern und Berichten stehen
4. System/Stammdaten/Firmierung Übersicht der Firmierungen hat Spalten "Beschreibung" und "Abkürzung" diese umbenennen in "Firmenname" und "Firmierung"

Falls in einem System mehrere Firmierungen eingepflegt sind, ist es im Moment nicht möglich für einen Benutzer pro Firmierung eine Mailadresse einzustellen. Dies führt dazu, dass aus dem ERP-System Mails an Kunden/Lieferanten mit einer falschen Mailadresse gesendet werden können.

Um dieses Problem zu lösen, soll das Versenden von E-Mails unterschiedlicher Firmierungen im ERP-System gewährleistet werden.

1. In den Firmierungen soll ein neues Feld "Domain" eingefügt werden. Hier sollte ein Wert (nach Schema "test.de") hinterlegt werden können. Die Eingabe des Benutzer muss geprüft werden.

2. In den Benutzereinstellungen soll das Feld "E-Mail" wie folgt erweitert werden: 2.1. Ist eine Domain in den Firmierungen hinterlegt, werden die Eingaben hinter dem Feld angezeigt. 2.2. Der Benutzer kann dann seine Adresse eingeben (ohne Domainzusatz) Beim Versenden von Mails soll überprüft werden, welche Firmierung verwendet wird und die dazugehörige Mailadresse verwendet werden. 2.3. Falls der Benutzer eine komplette Mailadresse (mit Domain angibt) wird hinter dem Feld nichts angezeigt und diese E-Mail-Adresse wird im ERP-System genutzt 2.4. Zusätzlich soll ein Tooltip hinter das Feld angezeigt werden, welches die Funktionalität der Mail-Adresse erklärt.

Je nach ausgewählter Firmierung in den ERP-Dokumenten soll die jeweilige Mailadresse mit "@" zusammengefügt und in den Druckvorlagen bzw. als Absender von E-Mails ausgegeben werden.

master und Kundenbranches für Release 23.02

Momentan gibt es im Suchberichten der Artikelstammdaten, im Gegensatz zu andern Suchberichten des ERPs, keine Anzeige der aktiven Filtereinstellungen.

Das soll geändert d.h. den anderen ERP Suchberichten angeglichen werden.

In bestimmten Fällen (Vertreter verlässt Unternehmen) ist es notwendig, dass Provisionsregeln für einen bestimmten Zeitraum aktiv gesetzt werden können.

Deshalb soll in den Provisionsregeln unter dem Feld "Startdatum" ein neues Feld "Enddatum" hinzugefügt werden. Dieses Feld muss nicht gesetzt werden, wird es aber gesetzt, ist die Provisionsregeln ab diesem Datum nicht mehr gültig.

Im Zuge dessen sollen die Überschriften im Bericht "Verkauf/Berichte/Vertreterabrechnung" wie folgt angepasst werden: Von "Übersicht zur Vertreterabrechnung" zu "Übersicht zur Vertreterabrechnung aus Provisionsregeln" und von "Vertreterabrechnung" zu "Vertreterabrechnung aus Provisionsregeln".

Außerdem soll in der Übersicht zur Vertreterabrechnung neben dem Umsatz auch die Provision angezeigt werden.

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.

Der Name der zip-Datei, die beim DATEV-Export ausgegeben wird, soll folgendes Format haben: [Firmierungsname]-odyn-erp-datev-exportvon[Startdatum]-[Enddatum]am[Ausführungsdatum]mitBelegen.zip

• Datumsformat YYYYMMDD
• Der Teil "mitBelegen" soll nur angehängt werden, wenn Belege mit exportiert werden

In der Vertreterabrechnung werden die Summen der Provision intern mit ungerundeten Werten berechnet, aber im Bericht gerundet dargestellt. Dadurch kann die dargestellte Summe einer Rechnung von der Summe der dargestellten Einzelwerte abweichen.

Um die Berechnung nachvollziehbar zu gestalten, soll die Provision pro Position ungerundet dargestellt werden. Die Summe pro Rechnung soll auf volle Cent gerundet sein. Die Gesamtsumme des Berichts soll aus den Werten pro Rechnung berechnet werden.

Der Filter "Firmierung" im GuV-Bericht funktioniert nicht. Egal welche Firmierung gesetzt wird, die Ergebnisse des Berichts werden nicht an die Firmierung angepasst und sind immer gleich.

Der Filter "Firmierung" im GuV-Bericht soll funktionieren.

Die Auswahlliste der Zahlungsbedingungen in Aufträgen ist nicht korrekt sortiert. Auch in den Tabellen unter System/Zahlungsbedingungen werden die Einträge unsortiert angezeigt. Es ist außerdem nicht möglich, die Sortierung der Zahlungsbedingungen für den Verkauf zu ändern.

Zahlungsbedingungen sollen immer korrekt sortiert angezeigt werden. Das Umsortieren von Zahlungsbedingungen soll korrekt funktionieren.

Beim Druck von Kreditorenbuchungen kommt es zu einer Fehlermeldung, die den Druck verhindert.

Der Fehler soll behoben werden.

Wenn eine zusammengefasste Rechnung aus mehreren Lieferscheinen erstellt wird, wird der Bearbeiter aus den Lieferscheinen übernommen und nicht der Benutzer, der die Rechnungen erstellt hat.

Die Logik soll analog zur Logik im normalen Workflow implementiert werden. Hier wird der angemeldet Benutzer als Bearbeiter in der Rechnung eingetragen.

Wird in den Kundenstammdaten nach Kunden-/Lieferantentyp sortiert, kommt eine rote Fehlermeldung (Meldung in Tech. Info). Dieser Fehler muss behoben werden.

CSV-Importprofile können nicht unter dem selben Namen für verschiedene Typen gespeichert werden: Wenn man z.B. ein Profil für Ansprechpersonen speichert und anschließend unter dem selben Namen ein Profil für Lieferadressen, geht das Profil für Ansprechpersonen verloren.

Es soll möglich sein, den selben Namen für Profile unterschiedlicher Typen zu verwenden.

Beim Versenden von Mails kommt es zu folgender Fehlermeldung: "Can't call method "address" on an undefined value at […]/SL/Form.pm line 2075. " Dieser Fehler tritt auf, wenn man bereits einen Belegausdruck erstellt hat und in dem "E-Mail verschicken" Pop-up die Option "zuletzt erstellten Beleg" zu der Option "neuen Beleg ausdrucken" wechselt. Die Mail wird trotz Fehlermeldung gesendet.

Beim Wechseln der Optionen soll der Fehler nicht mehr vorkommen.

Unter Umständen kann es sein, dass in der Positionstabelle von Lieferantenaufträgen in Spalte "In LS" und "Nicht in LS" der Wert nicht gerundet wird. Dadurch wird eine Zahl mit sehr vielen Nachkommastellen angezeigt.

Außerdem ist die Darstellung von "Nicht in LS" bei Verwendung von Collis nicht in Collis sondern in der Einheit der Position

Bei der Anzeige sollen die Zahlen vom System gerundet werden.

Bei der Zuweisung von Kontobewegungen können auch bereits geschlossene Rechnungen zugewiesen werden. Dazu muss im Zuweisungsdialog der Haken "auch geschlossene Rechnungen anzeigen" gesetzt sein. Eine Zuweisung von bereits geschlossenen Gutschriften ist nicht möglich, da die Suche diese nicht aufführt.

Bei Verwendung des Filters "auch geschlossene Rechnungen anzeigen" sollen auch geschlossene Gutschriften gefunden werden.

Momentan wird beim Drucken einer QR-Code-Rechnung der Fehler "Es muss ein Kunde im QR-Code eingetragen sein." ausgegeben, wenn keine Stadt im Kunden hinterlegt wurde.

Falls keine Stadt im Kunden hinterlegt wurde, soll folgende Meldung ausgegeben werden: "Im gewählten Kunden muss eine Stadt eingetragen sein."

Bei der Erstellung der Versandvorbereitung wird viel Zeit benötigt. Dies liegt zum Teil an schlecht optimierten Queries. Die Queries sollen optimiert werden.

Kriterien das eine Position als "Fertig " gilt: Summe der folgenden Mengen muss >= Menge in der Auftragsposition sein

• Reserviert für Auftragsposition
• Reserviert für verknüpfte Lieferscheinposition
• Rückgemeldet aus verknüpfter AA (Rückgemeldete Positionen werden Reserviert)
• Verknüpfte Lieferscheinposition Menge ausgelagert

Der Bericht berücksichtigt insbesondere keine Firmierungen, es soll untersucht werden ob die Leistung verbessert werden kann indem Firmierungen die nur Dienstleistungen behandeln ausgeschlossen werden.

Es besteht außerdem ein Bug: Wenn eine Position zur Hälfte Produziert und abgefüllt ist und zur Hälfte aus dem Lager reserviert wird, zählt diese Position nicht als vollständig. Dieser wird in diesem Ticket behoben

Artikel R1644 hat eine negative verfügbare Menge. Da es für den Artikel keine Reservierungen gibt, sollte die verfügbare Menge gleich der gesamten Menge auf Lager sein.

Ein Script soll bei allen Artikeln die Mengen "auf Lager" und "verfügbar" prüfen und wenn nötig korrigieren.

In den Artikelstammdaten kann bei Artikeln mit Firmierung "LCW" der Produktionsort "Mannheim" ausgewählt, aber nicht gespeichert werden. Nach dem Speichern steht wieder "- keiner -" im Feld Produktionsort.

Es soll möglich sein, den Produktionsort "Mannheim" bei Artikeln mit Firmierung "LCW" zu hinterlegen.

Sobald der Bericht "i-Rechnungen" für die Firmierung "HDL" ausgeführt werden soll, wird dieser mit einem Fehler abgebrochen. Im Verlauf der Taskserver-Jobs wird eine benutzerunfreundliche Fehlermeldung ausgegeben.

Der Bericht "i-Rechnungen" soll korrekt funktionieren und Fehlermeldungen benutzerfreundlich gestaltet werden.

Beim Erstellen einer Anfrage im AN-Helfer wird eine Fehlermeldung ausgegeben.

Anfrage soll über AN-Helfer erstellt werden können.

Für eine schnellere Durchführung des Workflows in der Produktion soll ein Massendruck der erstellten Materiallisten ermöglicht werden.

In der Produktionauftrag-Suche wird ein weiterer Export eingefügt: Ausgewählte Produktionsaufträge drucken. So können ausgewählte Produktionsaufträge und Materiallisten gesammelt gedruckt werden nachdem sie im ERP erstellt wurden. Die einzelnen Dokumente werden nach Erstellung der gesammelten PDF im Tab Dokumente der ERP-Dokumente abgelegt.

Der Bericht "Bestellermittlung" soll wie folgt angepasst werden:

1. Verkaufsaufträge werden unter Umständen ohne Lieferdatum gespeichert, da Pender noch nicht weiß wann der Auftrag ausgeliefert wird. Im Bericht "Einkauf/Bestellermittlung" sollen Aufträge ohne Lieferdatum berücksichtigt werden, wenn nach Lieferdatum gefiltert wird.
2. Es soll eine Darstellung implementiert werden, in der der Benutzer sehen kann, in welchen Aufträgen der Artikel enthalten ist. Dies wird in Form einer neuen Spalte "VK-Aufträge" umgesetzt. In dieser werden alle Aufträge (als Link) angezeigt, in dem der Artikel vorhanden ist.
3. Es soll eine neue Spalte "Lagerbestand ohne Servicetechniker" implementiert werden. Hierbei soll der Lagerbestand ohne den Bestand in den Lagern Servicetechniker angezeigt werden.

Wenn eine zusammengefasste Rechnung aus mehreren Lieferscheinen erstellt wird, wird der Bearbeiter aus den Lieferscheinen übernommen und nicht der Benutzer, der die Rechnungen erstellt hat.

Die Logik soll analog zur Logik im normalen Workflow implementiert werden. Hier wird der angemeldet Benutzer als Bearbeiter in der Rechnung eingetragen.

Um die automatische Auswahl der Steuerzonen zu verbessern sollen folgende Punkte umgesetzt werden:

• Neues Merkmal "Kleinunternehmer" an Kunden/Lieferanten

• Neue Bedingung "Inland Kleinunternehmer" in Steuerzonen: Die Steuerzone soll dann ausgewählt werden, wenn Land des Kunden/Lieferanten = Land der Firmierung, und der Kunde/Lieferant als Kleinunternehmer markiert ist

• Für Kunden/Lieferanten ohne Länderkürzel soll das Land der ersten Firmierung bei Bestimmung der Steuerzone verwendet werden

• Info-Tooltips im Kunden/Lieferanten bei "Länderkürzel", "USt-IdNr." und "Kleinunternehmer", um Funktion bzgl. Steuerzone zu erklären

• Steuerzone im Kunden/Lieferanten entfernen

• Pro Land werden die Buchungsgruppen vertikal wiederholt (Tabelle mit Erlös- und Aufwandskonten) Zur Zeit wächst die Tabelle bei mehr als zwei Ländern horizontal über den Bildschirm hinaus und es kann nicht gescrollt werden

Überall wo das Feature "Speichern und schließen" implementiert wurde (Artikel-, Kunden/Lieferantenstammdaten,…), soll es nun die Möglichkeit geben, die Stammdaten zu schließen, ohne zu speichern.

Dazu soll ein Button "Schließen ohne Speichern" unter dem Menüpunkt "Speichern" implementiert werden. Die Logik dieses Button ist die gleiche wie bei "Speichern und schließen" nur dass nicht gespeichert werden soll.

1. Sobald in den benutzerdefinierten Variablen eines Kunden ein Vertreter gespeichert wurde, ist es nicht mehr möglich diesen wieder zu entfernen.

2. Außerdem kann momentan in den benutzerdefinierten Variablen jeder Lieferant als Vertreter ausgewählt werden. Es sollte allerdings nur möglich sein, Lieferanten mit dem Typen „Vertreter“ auszuwählen.

3. Wird die benutzerdefinierte Variable Vertreter leer gespeichert, soll der Vertreter aus der BDV entfernt werden.

4. In dem Suchfeld zur benutzerdefinierten Variable „Vertreter“ sollen nur Lieferanten mit dem Typ "Vertreter" angezeigt werden.

   • Dafür soll in den Einstellungen zu den benutzerdefinierten Variablen die neue Option "BUSINESS_DESCRIPTION" gesetzt werden können. Über diese soll ein Lieferantentyp eingestellt werden können, auf welchen der Picker eingeschränkt wird.

Beim Druck von Kreditorenbuchungen kommt es zu einer Fehlermeldung, die den Druck verhindert.

Der Fehler soll behoben werden.

Werden über Kontobewegungen zuweisen Gutschriften mit Skonto ausgewählt, werden unausgeglichene Buchungen erzeugt. Die Buchungen können durch erneutes Buchen der Gutschriften korrigiert werden.

Bei der Zuweisung von Kontobewegungen mit Skonto werden die korrekten Buchungen erzeugt.

Bei der Verwendung von Überschriftsartikeln in Aufträgen, Lieferscheinen und Rechnungen kommt es zu einer Fehlermeldung, dass die Menge größer 0 sein muss. Werden Überschriftsartikel eingefügt, kann keine Menge eingetragen werden, da das Feld ausgeblendet wird.

Die Verwendung von Überschriften in ERP-Dokumenten soll wieder funktionieren.

Bei Erstellung von Aufträgen wird die Menge der Positionen auf Null-Mengen geprüft. Hierbei werden auch 0-Komma Mengen als 0 erkannt. Die Prüfung auf Null-Mengen soll korrigiert werden, sodass auch 0-Komma-Mengen eingegeben werden können.