Benutzer-Werkzeuge

Webseiten-Werkzeuge


engine:procedures:om_modifysetsforbonitbenefs_ad

om_ModifySetsForBonItBenefs_Ad

Prozedur, um die Zuordnung von Artikel-Sets zu Verkaufs-Aktions-Benefits des Typs „Bonus-Artikel“ zu verwalten.

Hintergrund :
Der Benefit-Typ „Bonus-Artikel“ für Verkaufs-Aktionen bietet die Möglichkeit, sogenannte Sets von Artikeln definieren zu können, aus denen der Kunde sich ein oder mehrere Artikel aussuchen darf, die er kostenlos erhält - sofern die zur Verkaufs-Aktion definierten Bedingungen erfüllt sind.

Hinweise :

1.) Sofern ein Benefit bereits in einer AKTIVEN Verkaufs-Aktion verwendet wird (s. om_GetCampaignBenefits_Ad), kann die Zuordnung zu Artikel-Sets NICHT mehr geändert werden (ggf. gibt es dann also einen Fehler) !

2.) Bei einer neuen Zuordnung prüfen wir, ob das Set auf einer Artikel-Bedingung („ItemConditionID“) basiert, auf der ein anderes bereits dem Benefit zugewiesenes Set beruht. Wenn dem so ist, gibt es einen Fehler, denn zwei identsiche Sets für ein und dasselbe Bonus-Artikel-Benefit machen keinen Sinn.

3.) Ebenfalls einen Fehler gibt es bei einer Neu-Zuordnung, falls das Set bereits einem anderen Benefit zugeordnet ist. Grund für diese Einschränkung ist die Vereinfachung der Überprüfungslogik für einen Warenkorb.
Hintergrund : Es kann ja der Fall auftreten, daß mehrere Bonus-Artikel im Warenkorb enthalten sind, die jeweils zu mehreren Sets eines einzigen (Bonus-Item-)Benefits gehören können, aber nur eine bestimmte Konstellation tatsächlich erlaubt ist (aufgrund der „MaxQuantity“-Einstellung des Benefits, s. gleichnamiger Rückgabespalte von om_GetCampaignBonusItems_Ad). Um nun ein u.U. sehr zeitaufwendiges Durchprobieren von Kombinationen zu vermeiden, müssen wir also für jeden Bonus-Artikel im Warenkorb wissen, zu welchem Set welches Benefits er gehört. Zwecks Reduzierung der damit eigentlich notwendigen ZWEI Informationen (Set UND Benefit) auf nur noch eine wird die Einschränkung der eindeutigen Zuordnung eines Sets zu einem Benefit gefordert.

Anmerkungen zum Parameter „SortNo“ :

1.) Mit der „SortNo“ steuert man die Reihenfolge der einem Bonus-Artikel-Benefit zugeordneten Sets. Die Werte beginnen bei „1“ und sind lückenlos aufsteigend (je niedriger der Wert desto höher die Priorität). Und weil der Datentyp „tinyint“ ist, können „BenefitID“ somit maximal 255 Sets zugeordnet werden

2.) Bei Neu-Anlage einer Zuordnung beachten wir „SortNo“ NICHT sondern vergeben automatisch den nächst größeren Wert.

3.) Bei einer Änderung (existiert die Zuordnung und ist „DeleteCombination = 0“) MUSS „SortNo“ auf jeden Fall angegeben werden und muß zwischen „1“ und der maximalen „SortNo“ eines zugeordneten Sets liegen. In diesem Fall sorgen wir übrigens automatisch dafür, daß nach der Änderung die „SortNo“s aller Sets garantiert wieder lückenlos aufsteigend (bei „1“ beginnend) sind.

4.) Im Löschen-Fall erniedrigen wir die „SortNo“ anderer Sets mit einem Wert „> SortNo“ um „1“.

HTTP-MethodPOST
HTTP-AuthOptional
Aliasom_ModifySetsForBonusItemBenefits_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
BenefitID ID eines Bonus-Items-Benefits (mögliche Werte : s. om_GetCampaignBonusItems_Ad). Hinweis : Wenn der Benefit bereits in einer AKTIVEN Verkaufs-Aktion verwendet wird (s. om_GetCampaignBenefits_Ad), kann NICHTS mehr verändert werden !
integer7.0.4
ItemSetID ID eines Bonus-Artikel-Sets (mögliche Werte : s. om_GetBonusItemSets_Ad). Gibt es die Zuordnung zu „BenefitID“ noch nicht, wird sie erstellt, sonst wird sie je nach „DeleteCombination“ geändert oder gelöscht.
integer7.0.4
SortNoNULL Bestimmt die Reihenfolge von „ItemSetID“ innerhalb aller „BenefitID“ zugeordneter Sets. Wird nur beachtet, wenn die Zuordnung „BenefitID“ zu „ItemSetID“ existiert - und ist in diesem Fall auch Pflicht (s. Beschreibung).
tinyint7.0.4
DeleteCombination0 Falls die Zuordnung von „BenefitID“ zu „ItemSetID“ schon existiert, gibt man hier an, ob sie geändert („0“) oder gelöscht („1“) werden soll
bit7.0.4

Rückgabe

Die Prozedur hat keine Rückgaben.

Output-Parameter

Die Prozedur hat keine Output-Parameter.

Mögliche Return-Codes

Code Beschreibung Quelle 4)
-1222Ein Set darf nicht verschiedenen Bonus-Artikel-Benefits zugeordnet werdennur direkt
-1220Einem Benefit können nicht zwei Sets mit derselben Artikel-Bedingung zugeordnet werdennur direkt
-1219Die Set-Zuordnung kann nicht geändert werden, weil der Benefit einer aktiven Campaign zugeordnet istnur direkt
-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]
7.0.4 2014-03-19Erstmalig 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_ModifySetsForBonItBenefs_Ad?BenefitID=<value>&ItemSetID=<value>'

Mit xmllint 5) formatierte Ausgabe:

curl -X POST  'http://<partner>-<project>.dstore.de/default/engine/om_ModifySetsForBonItBenefs_Ad?BenefitID=<value>&ItemSetID=<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_ModifySetsForBonItBenefs_Ad',
		array(
			'BenefitID' => <value>,
			'ItemSetID' => <value>,
			// 'SortNo' => NULL,
			// 'DeleteCombination' => 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_ModifySetsForBonItBenefs_Ad">
			<Parameters>
				<Parameter Name="BenefitID"><!-- integer value --></Parameter>
				<Parameter Name="ItemSetID"><!-- integer value --></Parameter>
				<!-- <Parameter Name="SortNo">NULL</Parameter> -->
				<!-- <Parameter Name="DeleteCombination">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_modifysetsforbonitbenefs_ad.txt · Zuletzt geändert: 11.01.2016 (Externe Bearbeitung)