Erstellt, löscht oder „ändert“ Aufschläge/Rabatte zu Versandarten.
Zum grundlegenden Verständnis : Es können zu einer Versandsart GAR KEINE „Surcharges“ oder genau ein „Surcharge“ oder MEHRERE „Surcharges“ hinterlegt sein, wobei diese Zuordnung immer für einen bestimmte Zeitraum gilt. Falls MEHRERE „Surcharges“ zugeodnet sind, ist es bedeutsam, daß diese „priorisiert“ werden - mit der sogenannten „PriorityNo“ (→
gleichnamiger Parameter). Diese bestimmt nicht bloß die Reihenfolge, in der die „Surcharges aufzulisten“ sind, sondern auch die Berechnungs-Grundlage für den jeweiligen „Surcharge“, genauer : Die Berechnungs-Grundlage für einen „Surcharge“ ist immer der Warenwert PLUS bereits errechnete „Surcharges“ mit höherer Priorität, sprich NIEDRIGERER „PriorityNo“ ! Das bedeutet insbesondere, daß „Surcharges“ mit DERSELBEN „PriorityNo“ DIESELBE Berechnungs-Grundlage bekommen.
Die genauere Funktionalität der Prozedur im einzelnen :
1. Fall : Zum Zeitpunkt „ValidFrom“ (bei „NULL“ : aktueller Zeitpunkt) gibt es die Kombination aus „ShippingTypeID“ und „SurchargeTypeID“ schon (der Gültigkeitszeitraum muß aber nicht notwendigerweise mit „ValidFrom“ beginnen).
Es sind diverse Unter-Fälle zu unterscheiden :
a) „DeleteConfiguration = 1“
Es muß „ValidFrom“ in der Zukunft liegen UND es muß einen Zeitraum geben, der mit „ValidFrom“ beginnt (d.h. es muß sozusagen ein eindeutig identifizierbarer Datensatz, komplett in der Zukunft liegend, existieren), sonst gibt es einen Fehler. Ist dem aber so, dann wird :
(i) Der identifizierte Datensatz gelöscht
UND
(ii) Ein evtl. vorhandener Datensatz zur „ShippingTypeID-SurchargeTypeID“-Kombination mit „ValidFrom“ als ENDE des zugehörigen Gültigkeitszeitraums wird geändert, und zwar wird das Ende auf dasjenige des in (i) gelöschten Datensatzes gesetzt. Dadurch wird quasi die zu löschende Zuordnung durch die unmittelbar zuvor geltende Konfiguration ersetzt, um zu verhindern, daß „Lücken“ entstehen oder z.B. unbeabsichtigt ab „ValidFrom“ KEIN „Surcharge“ mehr existiert.
b) „DeleteConfiguration = 0“ UND durch „ValidFrom“ kann ein Datensatz EINDEUTIG identifiziert werden UND „SurchargeValue“ ist NICHT „NULL“
Es wird ein Fehler geworfen, falls der Datensatz komplett (also das Ende des Gültigkeitszeitraums) in der Vergangenheit liegt. Ansonsten wird entweder …
oder
c) „DeleteConfiguration = 0“ UND durch „ValidFrom“ kann ein Datensatz EINDEUTIG identifiziert werden UND es ist „NULL“ für „SurchargeValue“ übergeben worden
Es wird ein Fehler geworfen, falls der Datensatz komplett (also das Ende des Gültigkeitszeitraums) in der Vergangenheit liegt. Andernfalls erledigen wir folgendes :
(i) Der Gültigkeitszeitraum des identifizierten Datensatzes wird abgeschlossen (mit dem aktuellen Zeitpunkt), falls „ValidFrom“ in der Vergangenheit liegt
UND
(ii) Alle Konfigurationen zur „ShippingTypeID-SurchargeTypeID“-Konfiguration, deren Zeitraum sich HINTER (einschl.) „ValidFrom“ bzw. dem aktuellen Zeitpunkt (falls „ValidFrom“ in der Vergangenheit liegt) befindet, werden gelöscht.
Anmerkung : Dies ist sozusagen die Funktionalität „Die Konfiguration X soll für eine bestimme Kombination aus „ShippingTypeID“ und „SurchargeTypeID“ die letzte sein (muß aber wenigstens noch „bis jetzt“ gelten)“.
d) „DeleteConfiguration = 0“ UND es kann KEIN Datensatz mit „ValidFrom“ als Gültigkeitszeitraum-Beginn identifiziert werden (insbesondere weil z.B. „NULL“ angegeben wurde)
Es gibt einen Fehler, falls „ValidFrom“ in der Vergangenheit liegt ! Andernfalls wird folgendes durchgeführt :
(i) Das Ende des Gültigkeitzeitraums der zum Zeitpunkt „ValidFrom“ geltenden Konfiguration wird auf „ValidFrom“ gesetzt.
UND
(ii) Sofern „SurchargeValue“ NICHT „NULL“ ist, wird ein neuer Datensatz zur „ShippingTypeID-SurchargeTypeID“-Kombination mit „ValidFrom“ als Beginn angelegt, wozu natürlich „SurchargeValue“ und „PriorityNo“ gespeichert werden. Das Ende des Gültigkeitszeitraums dieses neuen Datensatzes richtet sich danach, ob es eine noch weiter als „ValidFrom“ in der Zukunft liegende Konfiguration (zu „ShippingTypeID“ und „SurchargeTypeID“ natürlich) gibt. Falls ja, wird als Ende der Beginn der am nächsten (nach „ValidFrom“) in der Zukunft liegenden Konfiguration gewählt, sonst das maximal mögliche Datum („31.12.9999 23:59:59.999“).
2. Fall : Zum Zeitpunkt „ValidFrom“ (bei „NULL“ : aktueller Zeitpunkt) gibt es die Kombination aus „ShippingTypeID“ und „SurchargeTypeID“ noch NICHT.
Ist „SurchargeValue = NULL“ oder liegt „ValidFrom“ in der Vergangenheit, gibt es einen Fehler ! Ansonsten wird ein neuer Datensatz zur „ShippingTypeID - SurchargeTypeID“-Kombination mit „ValidFrom“ als Beginn angelegt, wozu natürlich „SurchargeValue“ und „PriorityNo“ gespeichert werden. Das Ende des Gültigkeitszeitraums dieses neuen Datensatzes richtet sich danach, ob es eine noch weiter als „ValidFrom“ in der Zukunft liegende Konfiguration (zu „ShippingTypeID“ und „SurchargeTypeID“ natürlich) gibt. Falls ja, wird als Ende der Beginn der am nächsten (nach „ValidFrom“) in der Zukunft liegenden Konfiguration gewählt, sonst das maximal mögliche Datum („31.12.9999 23:59:59.999“).
HTTP-Method | POST |
HTTP-Auth | Optional |
Alias | om_ModifyShippingTypeSurcharges_Ad |
Tags | |
Engine-Kategorie | order management |
Engine-Typ | Daten-Änderung |
Letzte Aktualisierung | 7.0.7 (2015-01-29) |
Name 1) | Standard-Wert | Beschreibung 2) | SQL-Datentyp3) | ab Version |
---|---|---|---|---|
ShippingTypeID | ID einer Versandart | tinyint | 6.0.2 | |
SurchargeTypeID | ID einer Preis-Aufschlags/Rabatt-Art, die bei der Versandartt „ShippingTypeID“ anfällt, wie z.B. „Porto und Versicherung“ o.ä. Kann auch „NULL“ sein (wenn keine Kosten/Rabatte entstehen bzw. gewährt werden). | smallint | 6.0.2 | |
SurchargeValue | Wert zur „SurchargeTypeID“, der „ShippingTypeID“ zugewiesen werden soll (negativ : Rabatt, positiv : Aufschlag). „NULL“ bedeutet, daß ab „ValidFrom“ bzw. dem aktuellen Zeitpunkt KEIN Wert zur „SurchargeTypeID“ konfiguriert sein soll (s. Beschreibung). | decimal(16,6) | 6.0.2 | |
ValidFrom | NULL | Zeitpunkt ab wann der „Surcharge“ zur Zahlungsart gelten soll - bei „NULL“ wird der aktuelle Zeitpunkt gewählt. Falls angegeben und eine neue Konfiguration angelegt werden soll, muß es ein Wert in der Zukunft sein. s. Beschreibung ! | datetime | 6.0.2 |
PriorityNo | 1 | Bestimmt die Priorität des „Surcharges“. Berechnungs-Grundlage eines „Surcharge“ ist : Warenwert PLUS errechnete „Surcharges“ höherer Priorität, d.h. NIEDRIGERER „PriorityNo“. Pflicht-Angabe falls „SurchargeValue“ NICHT „NULL“ ist. s. Beschreibung ! | tinyint | 6.0.2 |
DeleteConfiguration | 0 | Falls es die Kombination „ShippingTypeID“-„SurchargeTypeID“-„ValidFrom“ („ValidFrom = NULL“ ⇒ aktueller Zeitpunkt) gibt, bestimmt dieser Wert, ob zu bearbeiten („0“) oder zu löschen („1“) ist. Löschen nur mögl. wenn „ValidFrom“ in der Zukunft liegt! | bit | 6.0.2 |
Die Prozedur hat keine Rückgaben.
Die Prozedur hat keine Output-Parameter.
Code | Beschreibung | Quelle 4) |
---|---|---|
-569 | Der Benutzer hat kein Ausführungsrecht für die Prozedur | nur indirekt |
-567 | Die Prozedur darf z. Zt. nicht ausgeführt werden | nur indirekt |
-566 | Die Prozedur darf mit den übergebenen Parametern nicht ausgeführt werden | nur indirekt |
-535 | Das Datum liegt nicht in der Vergangenheit | nur indirekt |
-530 | Der Wert ist nicht konvertierbar | nur indirekt |
-510 | Der Benutzer ist nicht registriert | nur indirekt |
-504 | Es ist ein Problem aufgetreten, das nicht gelöst werden kann, Prozedur wird daher abgebrochen | nur indirekt |
-500 | Falsche Parameter | direkt und indirekt |
Die Rückgabe erfolgt als XML-Dokument welches gegen das Schema Response/EngineProcedure_v1_0.xsd validiert.
7.0.7 | 2015-01-29 | Interne Änderung : Datentyp-Erweiterung des „ReferenceKey“ [für „_mi_StartProcedure“-Aufruf] |
7.0.4 | 2014-03-19 | Kleine Kosmetik-Korrektur : Bei einigen Code-Zeilen war am Ende ein CR-Zeichen, was wir entfernt haben |
6.0.2 | 2011-06-08 | Erstmalig in dieser Version erstellt |
Der folgende Link öffnet in einem separaten Fenster den Engine Playground der fest mit dem dbap-demo System verbunden ist:
Unformatierte Ausgabe:
curl -X POST 'http://<partner>-<project>.dstore.de/default/engine/om_ModifyShippingTypeSurch_Ad?ShippingTypeID=<value>&SurchargeTypeID=<value>&SurchargeValue=<value>'
Mit xmllint 5) formatierte Ausgabe:
curl -X POST 'http://<partner>-<project>.dstore.de/default/engine/om_ModifyShippingTypeSurch_Ad?ShippingTypeID=<value>&SurchargeTypeID=<value>&SurchargeValue=<value>' | xmllint --format -
use dStore_php\WebService; $service = new WebService\Service( WebService\Scheme::HTTP,'<partner>-<project>.dstore.de', 80); $request = new WebService\Requests\Engine\Procedure\Request( new WebService\Requests\AccessData('default'), 'om_ModifyShippingTypeSurch_Ad', array( 'ShippingTypeID' => <value>, 'SurchargeTypeID' => <value>, 'SurchargeValue' => <value>, // 'ValidFrom' => NULL, // 'PriorityNo' => 1, // 'DeleteConfiguration' => 0 ) ); $service->execute($request); $xml_result = $request->getResponse()->getBody()->toSimpleXmlDocument(); $ResultSet = $xml_result->getRowsAsArray();
XML zur Ausführung mit der Methode engine/execute, z.B. per
curl --header 'Content-Type: application/xml' -X POST 'http://<partner>-<kunde>.dstore.de/default/engine/execute' -d '<xml-daten>'
<?xml version="1.0" encoding="UTF-8"?> <ListOfBatches> <Batch No="0"> <Procedure Name="om_ModifyShippingTypeSurch_Ad"> <Parameters> <Parameter Name="ShippingTypeID"><!-- tinyint value --></Parameter> <Parameter Name="SurchargeTypeID"><!-- smallint value --></Parameter> <Parameter Name="SurchargeValue"><!-- decimal value --></Parameter> <!-- <Parameter Name="ValidFrom">NULL</Parameter> --> <!-- <Parameter Name="PriorityNo">1</Parameter> --> <!-- <Parameter Name="DeleteConfiguration">0</Parameter> --> </Parameters> </Procedure> </Batch> </ListOfBatches>