Problembeschreibung:

Wurde bei einer Teilschlussrechnung eine erhaltene Anzahlung zwecks Betragsdeckelung gesplittet, wurde in die ursprüngliche Kontierungszeile der erhaltenen Anzahlung das Buchungsdatum der erhaltenen Anzahlung als Zahldatum eingestellt. Infolgedessen wurde die erhaltene Anzahlung auf einer rückwirkenden OP-Liste nach dem Buchungsdatum der erhaltenen Anzahlung, aber vor der Teilschlussrechnung, nicht mehr ausgewiesen. 

Lösung:

Nun wird das korrekte Zahlungsdatum, nämlich das Buchungsdatum der Teilschlussrechnung in die ursprüngliche erhaltene Anzahlung bereitgestellt. 

Problembeschreibung:

Der reine CAQ Export hat keine Stücklistendaten an Syncos übertragen. Es musste stets hilfsweise auch MES aktiviert werden. 

Lösung:

Es wird nun auch beim reinen CAQ Anbindung von oxaion an Syncos die Stücklistendaten zusätzlich zu den Artikeldaten exportiert. Eine "hilfsweise" MES-Aktivierung ist nicht mehr nötig (und sollte wieder DEAKTIVIERT werden, wo es ausschließlich zu diesem Zwecke angeschalten wurde) 

Problembeschreibung:

Beim Löschen der verarbeiteten MES-Schnittstellensätze kam es u.U. bei größerer Datensatzanzahl zu einer SQL-Server Exception. 

Lösung:

Durch einen programmtechnischen Umbau der Löschaktion wurde das Problem eliminiert und sollte nun auch bei großer Anzahl an Datensätzen nicht mehr zur ursprünglichen Fehlermeldung führen. 

Problembeschreibung:

Probleme in der oxaion -> Syncos Schnittstelle bei Wareneingangsprüfungen durch zu häufigen Export der QS-Schnittstellensätze aufgrund der SperrLogik von Wareneingängen. 

Lösung:

Es wurde programmtechnisch eine Optimierung durchgeführt, so dass die QS-Sätze nun nur noch an Syncos exportiert werden, sofern sich inhaltlich etwas ändert und somit nicht mehr mit jedem Entsperren des Wareneingangskopfes pauschal ein erneuter Export angeworfen wird.

Problembeschreibung:

Übergabe der Daten an die Syncos-Schnittstelle funktioniert nicht mehr 

Lösung:

Kompatibilität der Versionsstände oxaion vs. Syncos war nicht gegeben. 

Problembeschreibung:

Bei einem MES/InitialExport werden MASSENDATEN in die UMESAP exportiert. Das darf nicht parallel zur regulären Abarbeitung der UMESAP und auch nicht von verschiedenen Usern per Call parallel erfolgen. Der reguläre MES/CAQ-ExportJob muss beendet sein, denn dieser löscht ebenso Sätze aus der UMESAP, wie auch der MES-InitialExport bei gesetztem Flag.

Lösung:

• Absicherung durch gemeinsames FunctionLock.
• Zusätzliche Protokollierung, wann was angestoßen wurde.
• Technische Verbesserung von möglichen Fehlermeldungen.

Problembeschreibung:

Eine Auftragsenderückmeldung konnte nicht storniert werden, wenn der Referenzauftrag ein Innerbetrieblicher Auftrag ohne Projektbezug war.

Lösung:

Der Fehler wurde durch eine technischne Korrektur behoben.

Problembeschreibung:

Der Materialbedarf bei retrograden Materialbuchungen mit Fertigungsausschuss war teilweise nicht nachvollziehbar.

Lösung:

Der Materialbedarf bei retrograden Materialbuchungen mit Fertigungsausschuss wird nun für die akute Rückmeldung berechnet.

Problembeschreibung:

Bei Auftragsstart vergebene Chargennummern wurden initialisiert, aber nicht anlegt und nicht in den Fertigungsauftragskopf weggeschrieben.

Lösung:

Bei Auftragsstart vergebene Chargennummern werden nun angelegt und in den Fertigungsauftragskopf weggeschrieben.

Problembeschreibung:

Die Rückmeldebemerkung für seriennummernpflichtige Baugruppen setzte sich nach der Sortierreihenfolge im Auswahldialog zusammen,
so dass ein Bereich bspw. von "SN-00738 - SN-00734" statt wie erwartet "SN-00734 - SN-00738" ergab.

Lösung:

Beim Verbuchen der Seriennummern wurde die Sortierung auf Seriennummer eingeführt,
so dass die Sortierung im Auswahldialog keine Auswirkung auf die Zusammensetzung der Rückmeldebemerkung mehr hat.

Problembeschreibung:

Automatische Seriennummern mit numerischer Konstante wurden nicht richtig ermittelt.

Lösung:

Automatische Seriennummern mit numerischer Konstante werden nun richtig ermittelt.

Problembeschreibung:

Es gab ZUGFeRD-Rechnungen, die nicht verarbeitet werden konnten und im Protokoll eine NullPointerException im AbstractMailScanner ausgegeben haben.

Lösung:

ZUGFeRD-Rechnungen sind per Definition PDF-Dateien, die ein integriertes XML besitzen.
Bei der Püfung, ob es sich um eine ZUGFeRD-Rechnung handelt, wurde eine zusätzliche Variante eingebaut, um an den Dateityp des integrierten Files zu gelangen.

Problembeschreibung:

Wenn ein Lieferant eine ZUGFeRD-Rechnung mit groß geschriebener Dateienden (.PDF) verschickt hat, wurde das Rechnungsdokument nicht als PDF erkannt.
Es wurde somit keine TIFF-Datei erstellt, aber archiviert, sofern ein Lieferant zugeordnet werden konnte.
Im ERW konnte dadurch kein Rechnungsdokument angezeigt werden.

Lösung:

Die Dateiendungen des Rechnungsdokuments für die TIFF-Erstellung wird nun unabhängig von Groß- oder Kleinschreibung auf ein PDF-Dokument geprüft.

Problembeschreibung:

Neue Excel- oder Word-Dokumente im DMS wurden nicht korrekt, sondern leer angelegt.

Lösung:

Der technische Fehler wurde korrigiert, sodass neue Dokumente im DMS korrekt abgelegt werden.

Problembeschreibung:

Bei aktivierter restrukturierter VKS-FIBU-Übergabe kam es beim Stornieren einer Rechnung mit umzulegenden Versandkosten (d.h. Parameter 'Art der Leistung' in Tabelle FRD139 steht auf 'Nebenleistung')
zum Fehler FBU2093 (Differenz zwischen Personen- und Sachkonten), sodass sich die Storno-Rechnung nicht an die FIBU übergeben ließ.

Lösung:

Die FIBU-Übergabe für VKS-Stornorechnungen wurde korrigiert.

Problembeschreibung:

Eine Rechnung, deren Buchungsdatum in einer geschlossenen Periode liegt, konnte nicht in das System geladen werden.

Lösung:

Rechnungen werden jetzt auch dann in das System geladen, wenn ihr Buchungsdatum in einer geschlossenen Periode liegt. Im weiteren Prozess kann der Sachbearbeiter nun entscheiden, wie damit verfahren werden soll.

Problembeschreibung:

Ab März 2025 muss für den ELSTER-Import (CSV-Datei) die zusammenfassende Meldung (ZM) in Deutschland gemäß der Version 3.0 angeliefert werden.
So muss der Dateiinhalt nach UTF-8 codiert (Zeichencodierung) sein und die Umsatzsteueridentifikation wird nicht mehr getrennt (Länderkennung u. USt.Id.Nr.) ausgewiesen.

Lösung:

Die Bestimmungen wurden entsprechend umgesetzt.

Problembeschreibung:

Bei Einkaufsrechnungen in Fremdwährung kam es zu einem Fehler in der FIBU-Übergabe, wenn die Bestellung nicht in Fremdwährung erfasst war.

Lösung:

Die Restriktion für Einkaufsrechnungen bzgl. der Bestellwährung wurde aufgelöst.

Problembeschreibung:

Wurde in der Rechnungsprüfung eine Position abweichend zur Bestellung auf kostenlos gesetzt (Preisdimension '8'),
so erfolgte bei der restrukturierten EKS-FIBU-Übergabe die Korrekturbuchung zur Wareneingangsbuchung ('EX'-Buchung) mit dem Wert Null, statt mit dem Wert der Wareneingangsbuchung.

Lösung:

Die Korrekturbuchung erfolgt nun mit dem Wert der Wareneingangsbuchung.

Problembeschreibung:

Enthält die Schlussrechnung, für die es erhaltene Anzahlungen gibt, einen Technikerbeleg mit Ausführungsdatum, wird dieses in das Lieferdatum übertragen. Statt der Prüfung auf das Rechnungsdatum wird für die Bereitstellung des anzurechnenden Betrags das Lieferdatum verwendet. Wenn das Lieferdatum vor dem Buchungsdatum der erhaltenen Anzahlung liegt (weil der Techniker z. B. während seines ersten Einsatzes einen größeren Aufwand erkannt und eine Anzahlungsanforderung erstellt hat), werden diese deshalb bei der Schlussrechnung nicht angerechnet.

Lösung:

Für die Bereitstellung des anzurechnenden Betrags wird nun das Rechnungsdatum verwendet.

Problembeschreibung:

Eine Verkaufsrechnung mit prozentualem Positionsabschlag konnte nicht an die Finanzbuchhaltung übergeben werden, weil es Differenzen zwischen Haupt- und Nebenkonten gab. Die Ursache war, dass die restrukturierte Verkaufsfakturierung in diesem Fall falsch gerundet hat.

Lösung:

Bei prozentualen Positionszu-/abschlägen wird jetzt analog der alten Verkaufsfakturierung und der Auftragsposition gerundet. Damit gibt es keine Differenz mehr zwischen Personen- und Sachbewegungen und die Belege können an die Finanzbuchhaltung übergeben werden.

Problembeschreibung:

Bei einer manuell erstellten Einzelanfrage wurde bei mehrfachem Abruf neben der Anfrage immer auch die vorher abgerufene Bestellung auf erledigt gesetzt.

Lösung:

Nun wird nur die Anfrage selbst auf erledigt gesetzt, die bereits abgerufenen Bestellungen bleiben offen.

Problembeschreibung:

Bei Verwendung der restrukturierten Belegübergabe an die Finanzbuchhaltung wurden Stornobelege aus dem Einkauf nicht korrekt dargestellt (Kontenseite bzw. negative Beträge);
darüber hinaus schlug die Neuanlage eines Lieferantenartikels für eine Artikelnummer u.U. fehl, mit der Fehlermeldung, dass in der Datei ELFWEP bereits ein solcher Eintrag vorhanden sei.

Lösung:

Die restrukturierte Belegübergabe aus dem Einkauf an die Finanzbuchhaltung verwendet nun die Einstellung der TBV-Tabelle VRL F12 sowie den Parameter 07 der TBV-Tabelle VRL E20,
sodass die o.g. Fehler behoben sind.

Problembeschreibung:

Bei Belastungen ohne Retoure war es nicht mehr möglich, nur einen Preis und keine Menge einzugeben.
Zudem wurden bei der Übergabe an die FiBu im Lieferantenartikelstamm die Felder Umsatz, Bonusumsatz und Bonuswert mit falschem Vorzeichen gebucht.

Lösung:

Belastungen ohne Retoure sind nun wieder ohne Mengeneingabe möglich und der Lieferantenartikelstamm wird mit dem korrekten Vorzeichen bebucht.

Problembeschreibung:

Im ERW wurden die IBAN und Referenz aus dem Zahlteil einer QR-Rechnung nicht ermittelt.

Lösung:

Die Felder IBAN und Referenz werden nun im ERW aus dem Zahlteil einer QR-Rechnung ermittelt und gefüllt.

Problembeschreibung:

Bei Artikeln, die als Medizinprodukt oder Handelsware eingestellt sind, wurde beim Wareneingang bei der Lagerbuchung der Buchungswert u.U. nicht gefüllt.

Lösung:

Nun wird beim Wareneingang für Medizinprodukte & Handelswaren immer der korrekte Buchungswert ermittelt.

Problembeschreibung:

Technischer Fehler bei Dienstleistungsrechnungen auf Kopfsätzen, da eine Position abgefragt wird.

Lösung:

Technische Korrektur bei Dienstleistungsrechnungen auf Kopfsätzen, indem fehlende Position beachtet wird.

Problembeschreibung:

Normale Rechnungen (VKS, SAS, PRJ) ohne verrechnete Anzahlung wurden bei der Buchung in der Finanzbuchhaltung als bezahlt markiert.

Lösung:

Mit der Verbuchung einer ganz normalen Rechnung (ohne Verrechnung von Anzahlungen) wird die Rechnung als unbezahlt markiert.
Ist eine Anzahlung verrechnet worden, so ist die Rechnung ebenfalls unbezahlt, wenn die Anzahlung geringer als der Rechnungsbetrag war.

Problembeschreibung:

Bei der Aktualisierung der Datenbank traten technische Fehler auf, die u.U. zum Abbruch der Aktualisierung führten.

Lösung:

Die Aktualisierung der Datenbank wurde korrigiert, sodass der Vorgang erfolgreich durchgeführt wird.

Problembeschreibung:

Der Rechnungstyp wurde beim Start des Eingangsrechnungsworkflows nur noch bei Nutzung des OCR-Tools IRIS geladen.

Lösung:

Die Möglichkeit den Rechnungstyp bereits beim ERW-Launch einmalig initial vorzubelegen, wurde auf alle derzeit verfügbaren OCR-Tools ausgeweitet.

Problembeschreibung:

Bei der Installation der Datenbank traten technische Fehler auf, die zum Abbruch der Installation führten.

Lösung:

Die Installation der Datenbank wurde korrigiert, sodass die Installation erfolgreich durchgeführt wird.

Problembeschreibung:

Bei der Installation & Aktualisierung der Datenbank traten unter Umständen technische Fehler auf, die nicht korrekt verarbeitet wurden.

Lösung:

Die Installation & Aktualisierung der Datenbank wurde korrigiert, sodass technische Fehler korrekt verarbeitet und behandelt werden.

Problembeschreibung:

Bei der SEPA-Verarbeitung bei Zahlungen ins Ausland wurde der Zahlbetrag unter Umständen falsch bestückt.

Lösung:

Die Ausgabe des Zahlbetrags für die DTA-Schnittstelle wurde korrigiert.

Problembeschreibung:

Bei der Installation & Aktualisierung der Datenbank traten unter Umständen technische Fehler auf, die nicht korrekt verarbeitet wurden.

Lösung:

Die Installation & Aktualisierung der Datenbank wurde korrigiert, sodass technische Fehler korrekt verarbeitet und behandelt werden.

Problembeschreibung:

Bei der Implementierung der UDI-Generierung HIBC wurde ein Fall nicht mit beachtet, so das UDIs falsch ausgelesen und zusammengesetzt werden.

Lösung:

Die UDI-Generierung HIBC wurde um den fehlenden Fall ergänzt.