Benutzer-Werkzeuge

Webseiten-Werkzeuge


engine:procedures:om_modifypaymenttypesurch_ad

om_ModifyPaymentTypeSurch_Ad

Erstellt, löscht oder „ändert“ Aufschläge/Rabatte zu Zahlungsarten.

Zum grundlegenden Verständnis : Es können zu einer Zahlungsart 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 „PaymentTypeID“ 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 „PaymentTypeID-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 …

  • der Datensatz mit den in „SurchargeValue“ und „PriorityNo“ angegebenen Werten aktualisiert, falls „ValidFrom“ in der Zukunft liegt,

oder

  • der Gültigkeitkeitszeitraum des Datensatzes abgeschlossen (mit dem aktuellen Zeitpunkt) und ein neuer Datensatz angelegt, der mit dem aktuellen Zeitpunkt beginnt, das Ende des soeben abgeschlossenen Zeitraums besitzt und zu dem „SurchargeValue“ und „PriorityNo“ hinterlegt ist.

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 „PaymentTypeID-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 „PaymentTypeID“ 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 „PaymentTypeID-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 „PaymentTypeID“ 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 „PaymentTypeID“ und „SurchargeTypeID“ noch NICHT.

Ist „SurchargeValue = NULL“ oder liegt „ValidFrom“ in der Vergangenheit, gibt es einen Fehler ! Ansonsten wird ein neuer Datensatz zur „PaymentTypeID - 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 „PaymentTypeID“ 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-MethodPOST
HTTP-AuthOptional
Aliasom_ModifyPaymentTypeSurcharges_Ad
Tags
Engine-Kategorieorder management
Engine-TypDaten-Änderung
Letzte Aktualisierung7.0.7 (2015-01-29)

Parameter

Name 1) Standard-Wert Beschreibung 2) SQL-Datentyp3) ab Version
PaymentTypeID ID einer Zahlungsart
smallint6.0.2
SurchargeTypeID ID einer Aufschlags-/Rabattart (wie z.B. „Sonder-Rabatt“). Muß eine ID sein, die der „SurchargeTypeCategory“ für „Zahlungskosten“ (ID „4“) zugeordnet ist !
smallint6.0.2
SurchargeValue Wert zur „SurchargeTypeID“, der „PaymentTypeID“ 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
ValidFromNULL 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 !
datetime6.0.2
PriorityNo1 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 !
tinyint6.0.2
DeleteConfiguration0 Falls es die Kombination „PaymentTypeID“-„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 !
bit6.0.2

Rückgabe

Die Prozedur hat keine Rückgaben.

Output-Parameter

Die Prozedur hat keine Output-Parameter.

Mögliche Return-Codes

Code Beschreibung Quelle 4)
-569Der Benutzer hat kein Ausführungsrecht für die Prozedurnur indirekt
-567Die Prozedur darf z. Zt. nicht ausgeführt werdennur indirekt
-566Die Prozedur darf mit den übergebenen Parametern nicht ausgeführt werdennur indirekt
-535Das Datum liegt nicht in der Vergangenheitnur indirekt
-530Der Wert ist nicht konvertierbarnur indirekt
-510Der Benutzer ist nicht registriertnur indirekt
-504Es ist ein Problem aufgetreten, das nicht gelöst werden kann, Prozedur wird daher abgebrochennur indirekt
-500Falsche Parameterdirekt und indirekt

XML-Schema

Die Rückgabe erfolgt als XML-Dokument welches gegen das Schema Response/EngineProcedure_v1_0.xsd validiert.

Historie

7.0.7 2015-01-29Interne Änderung : Datentyp-Erweiterung des „ReferenceKey“ [für „_mi_StartProcedure“-Aufruf]
6.0.2 2011-06-08Erstmalig in dieser Version erstellt

Code-Snippets

Engine Playground

Der folgende Link öffnet in einem separaten Fenster den Engine Playground der fest mit dem dbap-demo System verbunden ist:

cURL

Unformatierte Ausgabe:

curl -X POST  'http://<partner>-<project>.dstore.de/default/engine/om_ModifyPaymentTypeSurch_Ad?PaymentTypeID=<value>&SurchargeTypeID=<value>&SurchargeValue=<value>'

Mit xmllint 5) formatierte Ausgabe:

curl -X POST  'http://<partner>-<project>.dstore.de/default/engine/om_ModifyPaymentTypeSurch_Ad?PaymentTypeID=<value>&SurchargeTypeID=<value>&SurchargeValue=<value>' | xmllint --format -
dStore_php
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_ModifyPaymentTypeSurch_Ad',
		array(
			'PaymentTypeID' => <value>,
			'SurchargeTypeID' => <value>,
			'SurchargeValue' => <value>,
			// 'ValidFrom' => NULL,
			// 'PriorityNo' => 1,
			// 'DeleteConfiguration' => 0
		)
);
 
$service->execute($request);
 
			$xml_result = $request->getResponse()->getBody()->toSimpleXmlDocument();
			$ResultSet = $xml_result->getRowsAsArray();
engine/execute

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_ModifyPaymentTypeSurch_Ad">
			<Parameters>
				<Parameter Name="PaymentTypeID"><!-- smallint 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>
1)
Pflichtparameter sind unterstrichen
4)
direkt meint „von der Prozedur selber“ und indirekt meint „von intern aufgerufenen Unterprozeduren“
5)
I.d.R. auf Unix-artigen Systemen bereits installiert, Bestandteil der libxml2, siehe http://www.xmlsoft.org
engine/procedures/om_modifypaymenttypesurch_ad.txt · Zuletzt geändert: 11.01.2016 (Externe Bearbeitung)