Zum Hauptinhalt springen

Upgrade auf 28.0.0

gefahr

Unbedingt die aktuellen Installationsvoraussetzungen vorab prüfen!

tipp

Diese Anleitung berücksichtigt immer nur den Sprung von der vorhergehenden Version zu der gerade beschriebenen Version. Bei Upgrades über mehrere Versionen hinweg müssen alle Änderungen der Zwischenversionen ebenfalls beachtet werden! Siehe genereller Ablauf von Upgrades.

Breaking Changes​

  • Die Tabelle vendorAccount hat eine neue Spalte recipient. Eigene Anpassungen, die Datensätze in vendorAccount importieren oder anlegen (z.B. eigene ERP-Anbindungen), müssen diese Spalte ab sofort mitbefüllen, da Lesezugriffe nun auch auf den Rechnungskreis filtern. (INV-799)
  • Das anpassbare Skript ou.spc.ptpINV.enumval.ptpInvoiceUser signalisiert einen Fehler bei der Enumerationsgenerierung nicht mehr über context.errorMessage/return -1, sondern loggt ihn nur noch (analog zu ou.spc.ptpINV.enumval.eInvoiceType). executeDirectly() gibt dadurch nicht mehr -1, sondern immer void zurück. Eigene Anpassungen dieses Skripts, die sich auf den bisherigen Rückgabewert -1 bzw. auf context.errorMessage verlassen, müssen entsprechend angepasst werden. (INV-840)
  • Das anpassbare Skript ou.spc.ptpINV.job.archiv wurde grundlegend umgebaut: Die Archivierungslogik liegt jetzt in der neuen Bibliothek ou.sp.ptpINV.lib.archive, das Skript enthält nur noch die Konfiguration. Bis auf executeDirectly() entfallen alle bisherigen Funktionen und Exporte. Fehler einzelner Mappen brechen den Job nicht mehr ab, sondern werden protokolliert. Bei der EEx-Archivierung wird die Mappe jetzt ebenfalls vor der Archivierung entsiegelt und im Supermodus verarbeitet. Bei der EDA-Adaptive-Archivierung wird die Mappe jetzt ebenfalls vor dem Löschen an den Job-Benutzer (JobUser) übertragen und landet damit in dessen Papierkorb. Eigene Anpassungen (z.B. ou.cust.ptpINV.job.archiv) müssen auf die neue Struktur übertragen werden; eigene Logik vor der Archivierung kann über die Option beforeArchiveCallback ergänzt werden (Beispiel siehe Kürzungen). (INV-856)
  • Die numerischen Spalten der Tabelle orderItem werden nun als DECIMAL statt als float gespeichert. Eigene Anpassungen, die diese Spalten als Zeichenkette lesen (z.B. über QueryIterator), erhalten die Werte nun mit fester Anzahl Nachkommastellen. Außerdem rundet selectWithOptions() (ou.sp.ptpINV.lib.rmb.orderItems) den Einzelpreis nicht mehr standardmäßig auf zwei Nachkommastellen; wird eine Rundung benötigt, muss sie über die Option rounding explizit angegeben werden. (INV-843)
  • Da der Bestell-Einzelpreis (itemOrderSingleAmount) nicht mehr auf zwei Nachkommastellen gerundet wird, werden Bestellpreise mit mehr als zwei Nachkommastellen (z.B. Stückpreis 0.0345 oder Stückpreis × Preiseinheit wie 0.03845 × 100) nun exakt mit dem Rechnungs-Einzelpreis (itemSingleAmount) verglichen. Das betrifft die Wareneingangsprüfung (validateOrderAndInvoiceSingleAmount), den Datenbankabgleich der Positionen sowie die Hervorhebung abweichender Einzelpreise im RMB-Monitor. Folgende Fälle melden dadurch nun eine Abweichung, die bisher durch die Rundung verdeckt wurde: Rechnungen, die den Einzelpreis mit nur zwei Nachkommastellen ausweisen (z.B. 3.85 gegenüber Bestellpreis 3.845), manuell mit zwei Nachkommastellen eingegebene Einzelpreise sowie ein erneuter Datenbankabgleich bei Rechnungen, die vor dem Update bereits mit Bestelldaten befüllt wurden (dort ist der Bestell-Einzelpreis noch gerundet gespeichert). Bestellpreise mit höchstens zwei Nachkommastellen sind nicht betroffen. Werden in der Bestellschnittstelle Preise mit mehr als zwei Nachkommastellen geliefert, sollte geprüft werden, ob die Prüfung über validateOrderAndInvoiceSingleAmount angepasst werden muss. (INV-843)

Zusammenfassung​

  • Die dialogTitle-Werte der Workflow-Aktionen "Weitere fachl. Prüfung" und "Zurück zur fachl. Prüfung" wurden von "Freigabe" auf "Prüfung" vereinheitlicht, sodass Button- und Dialog-Bezeichnung übereinstimmen. (INV-769)
  • Die Tabelle vendorAccount wurde um die Spalte recipient ergänzt, um Kontodaten bei rechnungskreisübergreifend doppelt vergebenen Lieferanten-IDs eindeutig zuordnen zu können. (INV-799)
  • Die Pflichtfeldprüfung der Datenextraktion (Status 15) wertet numerische Felder mit dem Wert 0 (z.B. Steuersatz und Steuerbetrag) nun nicht mehr fälschlicherweise als fehlend. Ein Feld gilt nur dann als nicht gesetzt, wenn es tatsächlich leer ist. (INV-797)
  • Beim Button "Rundungsdifferenz" wird der Steuerbetrag nun je Steuerschlüssel aus den Nettobeträgen der Positionen neu berechnet (statt die Positionssteuerbeträge nur aufzusummieren), wobei Soll/Haben berücksichtigt wird. Fehler beim Erstellen der Position werden dem Anwender nun im Dialog angezeigt. (INV-787)
  • Der Einzelpreis (singleAmount) konnte durch eine Floating-Point-Ungenauigkeit verfälscht angezeigt werden (z.B. 415.97 → 415.9700012207031), was beim Datenbankabgleich fälschlich zu "Teilweise Übereinstimmung" führte. Die betroffenen Lesepfade runden den Wert nun zuverlässig. (INV-795)
  • Die numerischen Spalten der Tabelle orderItem (quantity, singleAmount, quantityDelivered, priceUnit, vatRate) werden nun als DECIMAL gespeichert, und der in viewActiveOrderItems berechnete Einzelpreis wird auf einen festen DECIMAL-Typ gecastet. Damit entstehen keine Floating-Point-Ungenauigkeiten mehr, und der Einzelpreis aus der Bestellung wird beim Befüllen der Positionen sowie beim Datenbankabgleich nicht mehr auf zwei Nachkommastellen gerundet, sondern mit allen hinterlegten Nachkommastellen übernommen. (INV-843)
  • Im ROB- und RMB-Monitor wird nun auch die Spaltenbreite nutzerbezogen gespeichert; Reihenfolge und Breite lassen sich im Einstellungsdialog zurücksetzen. (INV-778)
  • In der Positionstabelle der Buchungsvorlagen-Konfiguration löste das Ändern des Nettobetrags einen clientseitigen Fehler aus, sodass die automatische Steuer- und Bruttobetragsberechnung nicht ausgeführt wurde. (INV-811)
  • Der manuelle Dashboard-Installer ("Invoice installieren") wurde entfernt; seine Installationslogik läuft nun automatisch über den Standard-Installer. (INV-790)
  • In der Freigabeliste wird der Eintrag des fachlichen Prüfers bei einer Betragsfreigabe nicht mehr überschrieben. Bisher wurde der Prüfer-Eintrag mit dem Freigeber überschrieben, wenn der Eintrag demselben Benutzer zugewiesen war, der später die Betragsfreigabe durchgeführt hat (z. B. weil die fachliche Prüfung von einem anderen Benutzer per "Aufgabe übernehmen" erledigt wurde). (INV-803)
  • Bei den Sachkonto-, Kostenstellen-, Kostenträger- und Bestellpositions-Lookups in der Positionstabelle werden nach Auswahl eines Datensatzes nun zuverlässig alle zurückgegebenen Spalten in die Zeile übernommen (row.setAll statt row.set). (INV-793)
  • Der Button "Rundungsdifferenz" muss nun nur noch einmal, anstatt wie bisher zweimal geklickt werden, wenn zuvor ein Kopfbetrag geändert wurde (z.B. in einem bearbeitbaren vatAmount-Feld). (INV-804)
  • Die von der MultiTable selbst bereitgestellten Buttons ("Kopieren und Einfügen", "Multi-Einfügen" und "Vollbild") werden im ROB- und RMB-Monitor nicht mehr rechts oben oberhalb der Tabelle angezeigt, sondern bilden eine eigene Button-Gruppe am Ende der übrigen Buttons. (INV-800)
  • Für RMB-Positionszeilen, auf die das Customizing "Positionen ohne Datenbankabgleich" zutrifft, wird der Datenbankabgleich nur noch dann übersprungen, wenn in der Datenbank keine passende Bestellzeile gefunden wird. Wird eine Bestellzeile gefunden, wird sie wie bisher verglichen und Abweichungen werden weiterhin als "Teilweise Übereinstimmung" gekennzeichnet. (INV-801)
  • Die im Standard noch nie verwendeten Felder ufApproval und ufGlobalState werden im Workflow nicht mehr befüllt. Zusätzlich wurde der Absendername der Eskalations-E-Mails von "Admin, Dehner" auf "One Unity, Admin" aktualisiert. (INV-806)
  • Beim Schreiben in die ptpData-Datenbank werden die Zeilen einer Mappe nun über uuid oder fileId identifiziert (doWriteTable(), doDeleteRow() in ou.sp.ptpINV.lib). Fehlte die uuid, lautete die Where-Bedingung bisher uuid = '' und hat damit die Zeilen aller anderen Mappen ohne uuid mitgelöscht. Sind uuid und fileId beide leer, wird kein Statement mehr ausgeführt und stattdessen ein Fehler gemeldet. (OUD-287)
  • Die Fußzeile im Invoice-Monitor zeigt nun Abweichungen, die innerhalb der Rundungstoleranz liegen, korrekt an. (INV-838)
  • Das ErpService-Interface wurde für den SAP Public Cloud Connector (SPCC) implementiert. (INV-658)
  • Die Aktion "Buchen (Vormonat)" steht nun auch im Status 90 ("Prüfen (Buchung)") zur Verfügung. Die Sichtbarkeit wird dort, wie beim normalen "Buchen", über ou.spc.ptpINV.workflow.access.booking gesteuert. (INV-812)
  • Beim Archivierungsjob werden Mappen ohne Positionsdaten nun archiviert. Schlägt das Schreiben der Positionsdaten in den Mappenkopf fehl, bleibt die Mappe im Umlauf. (INV-856)

Manuell auszuführende Schritte​

Datenbank (ptpData) (INV-799)​

Nach dem Update im Installer-Log prüfen, ob beim automatischen Befüllen der neuen Spalte recipient in vendorAccount nicht zuordenbare Datensätze gemeldet wurden (rechnungskreisübergreifend doppelt vergebene Lieferanten-IDs). Falls ja, muss für die betroffenen Rechnungskreise der jeweilige Import erneut angestoßen werden, damit diese Datensätze korrekt befüllt werden.

Datenbank (ptpData) (INV-843)​

Die Spalten der Tabelle orderItem werden während des Updates automatisch umgestellt:

Spaltealtneu
quantityfloatDECIMAL(18,6)
singleAmountfloatDECIMAL(18,6)
quantityDeliveredfloatDECIMAL(18,6)
priceUnitfloatDECIMAL(12,4)
vatRatefloatDECIMAL(10,4)

Unter MariaDB ist float nur ein 4-Byte-Gleitkommatyp mit ca. 7 signifikanten Stellen. Die vorhandenen Werte werden deshalb bei der Umstellung auf 7 signifikante Stellen, mindestens aber auf 2 Nachkommastellen gerundet, um die gespeicherte Ungenauigkeit zu entfernen. Werte mit mehr signifikanten Stellen (z.B. 1234567.89 oder 12.345678) konnten bereits zuvor nicht exakt gespeichert werden und werden erst durch einen erneuten Import der Bestelldaten wieder exakt übernommen. Unter MSSQL (float mit 8 Byte) werden die Werte direkt übernommen.

Zusätzlich wird die View viewActiveOrderItems neu erstellt, damit die berechnete Spalte singleAmount als DECIMAL(18,6) geliefert wird. Unter MSSQL werden außerdem die darauf aufbauenden Views viewActiveOrderItemsNotAssigned, viewDexproOrderItem und view_sfi_order_item per sp_refreshview aktualisiert.

gefahr

Ist in ou.spc.library.dbConnections für die Verbindung ptpData dropViews auf false gesetzt, wird viewActiveOrderItems nicht automatisch neu erstellt. In diesem Fall muss die Spalte singleAmount der View manuell auf CAST(orderItem.singleAmount * orderItem.priceUnit AS DECIMAL(18,6)) angepasst werden. Eigene Views oder Abfragen auf orderItem sollten auf Annahmen zum Datentyp float geprüft werden.

Workflow​

gefahr

Ab sofort dürfen Workflow-Anpassungen nicht mehr an bestehenden Workflow-Versionen vorgenommen werden. Stattdessen muss zwingend eine neue Workflow-Version erstellt werden (siehe Beschreibung in Ablauf von Upgrades)

Vereinheitlichung der dialogTitle-Werte "fachl. Prüfung" (INV-769)​

An zwei Workflow-Aktionen muss in der neuen Workflow-Version der dialogTitle angepasst werden, damit Button-Label und Dialog-Titel übereinstimmen:

  • Aktion workflow.ptpInvoice.action.additionalVerification ("Weitere fachl. Prüfung"): dialogTitle von Weitere fachl. Freigabe auf Weitere fachl. Prüfung ändern.
  • Aktion workflow.ptpInvoice.action.backToVerification ("Zurück zur fachl. Prüfung"): dialogTitle von Zurück zur fachl. Freigabe auf Zurück zur fachl. Prüfung ändern. Zusätzlich den AutoComment von zur fachlichen Freigabe auf zur fachlichen Prüfung ändern.

Entfernen der Legacy-Felder ufApproval und ufGlobalState (INV-806)​

An einigen Aktionen waren noch Custom-Felder – vermutlich aus einer alten Kunden-Version – hinterlegt, diese wurden nun entfernt:

  • Aktion workflow.ptpInvoice.action.export ("Buchen"): Feldbelegung -> ufApproval
  • Aktion workflow.ptpInvoice.action.exportPreviousMonth ("Buchen (Vormonat)"): Feldbelegung -> ufApproval
  • Entscheidung "Buchung Zielsystem ok?": Feldbelegung -> ufApproval
  • Aktion workflow.ptpInvoice.action.manualExport ("Gebucht (Manuell)"): Feldbelegung -> ufApproval und ufGlobalState

Neue Aktion "Buchen (Vormonat)" in Status 90 (INV-812)​

Neue Verbindung zwischen Status 90 ("Prüfen (Buchung)") und der Entscheidung vor dem Ausgangssignal ou.spc.ptpINV.workflow.sendsignal.export herstellen (gleiches Ziel wie die bestehende Aktion "Buchen" in Status 90):

Allgemein:

  • pf: workflow.ptpInvoice.action.exportPreviousMonth
  • Skript: runscript:ou.spc.ptpINV.workflow.guard.exportPreviousMonth
  • Kommentar: Buchung durchführen
  • Navigation: Nächste Mappe

Eigenschaften:

  • VisibilityGuard: runscript:ou.spc.ptpINV.workflow.access.booking

Portalskripte​

Diff wird geladen…