Upgrade auf 25.0.0
Unbedingt die aktuellen Installationsvoraussetzungen vorab prüfen!
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
- Workflow-ext wurde aufgelöst: clientHeaderCode in Portalskripte implementiert (INV-563)
- Das Invoice-Cover wurde in React implementiert und alle MultiTable-Gadgets durch ihr React-Äquivalent ersetzt (INV-536)
- Das neue Xtractor-Interface wurde für Insiders implementiert (INV-624)
- Dexpro wurde in den Invoice-Workflow integriert (INV-633)
- Es wurde ein Job für den Dexpro-Stammdatenupload implementiert und der Insiders-Stammdatenupload geändert/überarbeitet (INV-638)
- An den Rechnungskreis-Mappen müssen nun die zulässigen Währungen sowie die lokale Währung des Rechnungskreises konfiguriert werden. Darüber hinaus wird in den Positionszeilen der
ptpInvoiceMappen nun automatisch das korrekte Währungssymbol angezeigt (INV-595)
Was wurde gemacht?
Zusammenfassung
- Das Gadget-Skript
Gadget_ou.spc.filetype.folder.html.Counter, welches an den OrdnernptpInvoiceundptpInvoiceErrorverwendet wurde, wurde durch das neue SkriptGadget_ou.spc.ptpINV.folder.html.Counterersetzt (POM-442) - Am MultiTable für die Positionen gibt es nun einen Button zum Hinzufügen einer Zeile für die Rundungsdifferenz (INV-607)
- Durch Codeverbesserungen wurden alte Verhaltensweisen, wie Fehler geworfen wurden, auf den aktuellen Stand geändert (INV-602, INV-603)
- Wenn der fachliche Prüfer gleichzeitig der Freigeber ist und den Betrag freigeben darf, wird der Freigabepfad nun korrekt geupdated (INV-609)
- Am Button "zurück zur fachl. Prüfung" wurde das Skript-Parameter
verificationGroupentfernt (INV-647) - Wird an einer Kostenstellen-Mappe eine Änderung via dem Button 'Kostenstelle hinzufügen' durchgeführt, so wird nun die Trefferliste des Ordners 'Kostenstellenzuordnungen' aktualisiert. Außerdem wurden die Fehlermeldungen des Dialogs optimiert (INV-652)
- An Status 50 wurde ein zusätzlicher Workflow-Button eingefügt, der die Buchung auf den Vormonat im Standard ermöglicht (INV-617)
Manuell auszuführende Schritte
Auflösung von Workflow-Ext (INV-563)
Cover-Templates migrieren
Existiert ein Skript ou.cust.ptpINV.filetype.field.html.cover, so muss diesem Skript folgende Funktion hinzugefügt werden:
function getHtmlTemplate(name) {
var htmlProperties = context.getCustomProperties(name);
if (htmlProperties.size() <= 0) {
throw new Error(context.getFromSystemTable("PTPINV_HTML_ERROR_TEMPLATE_NOT_FOUND"));
}
var htmlTemplateProperty = htmlProperties.first();
if (!htmlTemplateProperty.value) {
throw new Error(context.getFromSystemTable("PTPINV_HTML_ERROR_TEMPLATE_EMPTY"));
}
return htmlTemplateProperty.value;
}
Anschließend muss überprüft werden, ob im selben Skript Custom-Templates definiert sind, diese sind wenn dann ab dieser Stelle zu finden:
module.exports = function (docFile) {
return {
// templateUrl: "ext/html/ou/cust/ptpINV/cover.html",
// templates: {
// global: {
// start: "ext/html/ou/cust/ptpINV/cover/global-start.html",
// end: "ext/html/ou/cust/ptpINV/cover/global-end.html",
// },
// vendor: {
// start: "ext/html/ou/cust/ptpINV/cover/vendor-start.html",
// end: "ext/html/ou/cust/ptpINV/cover/vendor-end.html",
// },
// cockpit: {
// start: "ext/html/ou/cust/ptpINV/cover/cockpit-start.html",
// end: "ext/html/ou/cust/ptpINV/cover/cockpit-end.html",
Wird hier ein Custom-Template definiert, so muss dieses Template als Globale Eigenschaft angelegt und anschließend mit der gerade hinzugefügten Funktion getHtmlTemplate geladen werden, z.B. so:
module.exports = function (docFile) {
return {
templates: {
global: {
start: getHtmlTemplate("ou.cust.ptpINV.filetype.field.html.cover.globalStart"),
end: getHtmlTemplate("ou.cust.ptpINV.filetype.field.html.cover.globalEnd"),
},
},
/* ... */
};
};
Skripte löschen
SP-Skripte
Folgende Skripte können gelöscht werden, da diese in Portalskripte verschoben wurden:
Workflow-ext/js/ou/sp/ptp/enum-callbacks-file.jsWorkflow-ext/js/ou/sp/ptp/mail-callbacks-file.jsWorkflow-ext/js/ou/sp/invplus/big.min.jsWorkflow-ext/js/ou/sp/invplus/invplus.calculationAmount.jsWorkflow-ext/js/ou/sp/invplus/invplus.calculationAmountMultiTable.jsWorkflow-ext/js/ou/sp/invplus/invplus.calculationCashDiscount.jsWorkflow-ext/js/ou/sp/invplus/invplus.configuration.jsWorkflow-ext/js/ou/sp/invplus/invplus.fieldMapping.jsWorkflow-ext/js/ou/sp/invplus/invplus.locale.jsWorkflow-ext/js/ou/sp/invplus/invplus.splitCalculationMultiTable.jsWorkflow-ext/js/ou/sp/invplus/invplus.utils.jsWorkflow-ext/js/ou/sp/invplus/invplus.validationAmountMultiTable.jsWorkflow-ext/css/ou/sp/invoice.css
Anschließend muss die Datei Workflow-ext/jsp/script-ousp-invoice.jsp entfernt werden.
cust-Skripte
Folgende Skripte wurden aus Workflow-ext/js/ou/cust/ptp/invoice/ in ein Portalskript verschoben und sind nun jeweils unter neuem Namen verfügbar:
Workflow-ext/js/ou/cust/ptp/invoice/calc-callbacks-file.js-->ou.sp.ptpINV.userexit.callbacks.calcWorkflow-ext/js/ou/cust/ptp/invoice/invoice-callbacks-file-functions.js-->ou.sp.ptpINV.userexit.functions.invoiceWorkflow-ext/js/ou/cust/ptp/invoice/invoice-callbacks-file.js-->ou.sp.ptpINV.userexit.callbacks.invoiceWorkflow-ext/js/ou/cust/ptp/invoice/rmb-callbacks-multiTable.js-->ou.sp.ptpINV.userexit.functions.rmbMultiTableWorkflow-ext/js/ou/cust/ptp/invoice/rob-callbacks-multiTable.js-->ou.sp.ptpINV.userexit.functions.robMultiTable
Existieren in einem der hier aufgeführten Skripte kundenspezifische Anpassungen, so müssen diese auch in ein Portalskript umgezogen werden – dies ist folgendermaßen zu tun:
Schritt 1: ClientHeaderCode-Skript kopieren
Falls es zum Skript ou.spc.ptpINV.clientHeaderCode noch kein gleichnamiges cust-Skript gibt, muss das spc-Skript kopiert und in ou.cust.ptpINV.clientHeaderCode umbenannt werden.
Schritt 2: Customizing migrieren
Nun gibt es zwei Möglichkeiten, wie sich das Customizing in einem der Skripte darstellt und entsprechend migriert werden muss:
Möglichkeit 1: Das Customizing bezieht sich direkt auf Code (z.B. auf eine Funktion oder die Registrierung eines User-Exit-Callbacks), der in dem mit dem Standard mitgelieferten Skript ebenfalls existiert. In diesem Fall muss also das betreffende sp-Skript kopiert und in ein cust-Skript umbenannt werden, wo dann das Customizing direkt übernommen wird.
Beispiel: Im Skript Workflow-ext/js/ou/cust/ptp/invoice/rob-callbacks-multiTable wurde die Funktion getImpersonalAccount angepasst. Das neue Skript ou.sp.ptpINV.userexit.functions.robMultiTable muss also kopiert und in ou.cust.ptpINV.userexit.functions.robMultiTable umbenannt werden. Dort wird nun das Customizing in die Funktion getImpersonalAccount übernommen.
Anschließend muss im Skript ou.cust.ptpINV.clientHeaderCode, um bei diesem Beispiel zu bleiben, im Array userExits der Eintrag "ou.sp.ptpINV.userexit.functions.robMultiTable" mit "ou.cust.ptpINV.userexit.functions.robMultiTable" ausgetauscht werden.
Möglichkeit 2: Das Customizing besteht aus einer Funktion oder einer Registrierung eines User-Exit-Callbacks, die im jeweiligen Standard-Skript nicht existiert. In diesem Fall kann einfach ein neues Portalskript angelegt werden, z.B. ou.cust.ptpINV.userexit.custFunctions.invoice, in welchem das Customizing dann platziert wird. Anschließend muss dieses Skript im Array userExits des Skripts ou.cust.ptpINV.clientHeaderCode eingetragen werden.
Funktionen, die in einem Skript definiert werden, die dann im clientHeaderCode Skript im Browser geladen werden, sind dort nicht mehr automatisch im globalen Scope verfügbar. Dies muss nun explizit gesetzt werden:
Vorher (z.B. Workflow-ext/js/ou/cust/ptp/invoice/rob-callbacks-multiTable):
function someFunction() {
// ...
}
Nachher (z.B. ou.cust.ptpINV.userexit.functions.robMultiTable):
window.someFunction = function () {
// ...
};
Nach erfolgreicher Migration der Skripte kann die Datei Workflow-ext/jsp/script-ousp-invoice.jsp entfernt werden.
Alle Skripte im Workflow-ext-Verzeichnis, die nicht mit dem Standard mitgeliefert werden, können ebenfalls nach der beschriebenen Methode in ein Portalskript migriert werden.
HTML löschen
Folgende HTML-Dateien können gelöscht werden, falls diese in keinem cust-Skript referenziert werden:
Workflow-ext/html/ou/sp/ptpREC/gadget_addresses.htmlWorkflow-ext/html/ou/cust/folderCounter.html
Folgende HTML-Dateien wurden in die Globalen Eigenschaften verschoben:
Workflow-ext/html/ou/sp/ptpINV/activities.html-->ou.sp.ptpINV.gadget.activitiesWorkflow-ext/html/ou/sp/ptpINV/cover.html-->ou.sp.ptpINV.coverWorkflow-ext/html/ou/sp/ptpINV/dashboard-monitoring.html-->ou.sp.ptpINV.gadget.monitoring
Falls diese HTML-Dateien in einem cust-Skript referenziert werden, muss dort jeweils stattdessen die Globale Eigenschaft geladen werden – anschließend können die HTML-Dateien gelöscht werden.
Datenbank (ptpData)
orderItem
Die Spalten in der Tabelle orderItem wurden die Spalten quantity und singleAmount auf den korrekten Datentyp float angepasst. Außerdem wurden die Anpassungen für die Stammdaten-Erweiterungen hinzugefügt.
Vor der Datenbankmigration ist unbedingt zu prüfen: Sind die aktuellen Daten in orderItem für quantity und singleAmount in einem Format, welches automatisch migriert werden kann? (siehe Tabelle)
Konvertierung von String -> Float
| Beispielwert | mssql | mariaDB |
|---|---|---|
| 1.63 (engl. Dezimalkennzeichen) | ✅ | ✅ |
| 1.63 (whitespace davor / danach) | ✅ | ✅ + Warnung |
| 1,63 (dt. Dezimalkennzeichen) | ⛔ | ⛔ |
| 1_63 | ⛔ | ⛔ |
| 1.000,63 | ⛔ | ⛔ |
| 1. 63 | ⛔ | ⛔ |
Falls das aktuelle Format passt, kann die Anpassung automatisch über das Datenbankscript ausgeführt werden.
Es ist unbedingt zu prüfen, ob bei Customizing der Views viewActiveOrderItems bzw. viewActiveOrderItemsNotAssigned in den Spalten quantity und singleAmount nun der korrekte Datentyp zurückkommt!
recipientCurrencies
Diese Tabelle wurde hinzugefügt.
recipient
Erhält eine neue Spalte localCurrency sowie die Anpassungen für die Stammdaten-Erweiterungen.
Stammdaten-Erweiterungen (neue Spalten)
vendor, recipient, costcenter, orderItem
Den Tabellen wurden die Spalten externalId und lastModified hinzugefügt.
invoiceState
Der Tabelle invoiceState wurden die Spalten erpInvoiceNumber, bookingDate und bookingYear hinzugefügt.