Ermittelt zu einer Menge von Artikel-Elementen bzw. Elementen des Artikelbaums die Verkaufspreise.

Im folgenden eine kurze Erläuterung des Algorithmus für die Verkaufspreis-Ermittlung:

1. Grundpreis-Ermittlung

Für die Elemente, zu denen der (Verfaufs-)Preis ermittelt werden soll, wird zunächst die Eigenschaft zu dem (rekursiven) Merkmal ermittelt, dessen Bezeichnung mit „Verkaufspreis“ beginnt und das als „UnitID“ die durch „CurrencyID“ angegebene Währung besitzt.
Ist keine Wunschwährung (→ „CurrencyID“) angegeben oder hat ein Element keinen „Verkaufspreis“ in der (von der Standardwährung abweichend) angegebenen Währung, wird der Verkaufspreis in der Standardwährung (Eintrag in „Settings“ zum Schlüssel „DefaultCurrencyID“) ermittelt, und evtl. in die Wunschwährung (→ „CurrencyID“) umgerechnet.
ACHTUNG : Ist eine Umrechnung nicht möglich, bricht die Preisermittlung mit einem entsprechenden Fehler-Code ab !
Wurde eine „PriceNodeCharacteristicID“ angegeben, wird statt alledem die Preis-Eigenschaft zu diesem Merkmal gewählt; nur für die Elemente, die KEINE Eigenschaft zu diesem Merkmal besitzen, wird der „herkömmliche“ Verkaufspreis (wie eben beschrieben) genommen.
ACHTUNG : Kann für einige Elemente KEIN Verkaufspreis ermittelt werden, gibt es KEINEN Fehler, sondern es werden dann nur die Elemente zurückgegeben, für die ein Verkaufspreis gefunden wurde !

Anmerkung zum Parameter „PriceNodeCharacteristicID“ an dieser Stelle :

Dieser Parameter durchbricht ein wenig das Sicherheits-Konzept der „public“-Prozeduren (alle Prozeduren, deren Name NICHT auf „_Ad“ endet und nicht mit „_“ beginnt). Normalerweise kann ein öffentlicher Benutzer, der sich DIREKT auf dem Datenbank-Server anmeldet (was i.d.R. schon schwierig genug sein sollte…) NUR Daten einsehen oder verändern, für die Zugriffsrechte vorhanden sind. Beispielsweise kann (siehe im_ModifyLockedNodeCharacs_Ad) verhindert werden, daß der „publicuser“ Eigenschaften zu bestimmten Merkmalen einsehen kann - insbesondere bestimmte „Preise“ („Händler-EK“s o.ä.). Evtl. wird es in einer zukünftigen „dStore“-Version daher die Möglichkeit geben, Berechtigungen für Merkmale an den Personen-TYP zu binden o.ä.

2. Staffelpreis-Ermittlung (nur wenn in „Settings“ zum Schlüssel „CampaignSurchargesEnabled“ NICHT „1“ konfiguriert ist)

Sofern „PriceNodeCharacteristicID“ NICHT angegeben ist ODER der Wert „1“ in „Settings“ zum Schlüssel „AlwaysConsiderGraduatedPrices“ konfiguriert ist, werden nun sogenannte „Staffelpreise“ (zur jeweiligen angegebenen Menge [„Quantity“] passend) ermittelt. Zunächst wird der minimalste Staffelpreis in der gewünschten Währung ermittelt. Falls nicht vorhanden, und falls die Wunschwährung (→ „CurrencyID“) von der Standardwährung abweicht, wird dann versucht, den minimalsten Staffelpreis in der Standardwährung zu bestimmen (dieser - sofern vorhanden - wird dann natürlich umgerechnet).

3. Surcharge-Ermittlung (nur wenn in „Settings“ zum Schlüssel „CampaignSurchargesEnabled“ NICHT „1“ konfiguriert ist)

Wenn „PriceNodeCharacteristicID“ NICHT angegeben ist ODER der Wert „1“ oder „2“ in „Settings“ zum Schlüssel „AlwaysConsiderSurcharges“ konfiguriert ist, werden nun „Surcharges“ (Rabatte oder Aufschläge) verarbeitet.
Falls „NULL“ für den Parameter „PersonID“ angegeben wurde, erübrigt sich das natürlich, es sei denn für den erwähnten Schlüssel ist „2“ konfiguriert - dann wird der Parameter (intern) mit dem Wert „0“ überschrieben.
Anmerkung : s.u. „Grundsätzliches zu Surcharges“

Hinweis : Sofern in „Settings“ zum Schlüssel „CampaignSurchargesEnabled“ der Wert „1“ konfiguriert ist, finden die Schritte 2 und 3 NICHT statt. Stattdessen werden alle in Frage kommenden Verkaufs-Aktionen mit einem „SurchargeBenefit“ oder einem Bundle-Preis ermittelt und deren Bedingung(en) geprüft - falls eine oder meherere Aktion(en) zutrifft/zutreffen, werden sich daraus ergebende Rabatte dann im Schritt 4 berücksichtigt.

4. Preis-Berechnung

Abschließend wird der endgültige Preis anhand der bisher ermittelten Daten errechnet :
Wir gehen vom Grundpreis (der wie in 1. beschreiben ermittelt wurde) aus, es sei denn, wir haben einen Staffelpreis (→ 2.) gefunden, der günstiger ist. Auf diesen Preis wird dann ein evtl. ermittelter „Surcharge“ (→ 3.) angewandt. Wenn jedoch in „Settings“ zum Schlüssel „CampaignSurchargesEnabled“ der Wert „1“ konfiguriert ist, gehen wir vom Grundpreis (wie in 1. ermittelt) aus und wenden evtl. durch Verkaufs-Aktionen zutreffende Rabatte an.

Hinweis: In jeder der vier genannten Schritte (abgesehen von Schritt 2 und 3 falls „CampaignSurchargesEnabled“ auf „1“ konfiguriert ist !) kann „eingegriffen“ werden, sprich das Standardverhalten kann „überschrieben“ werden, und zwar durch das Konzept der sogenannte „Action“-Prozeduren (Name beginnt mit „_ac_“). Diese Prozeduren sind quasi das, was „trigger“ für Tabellen sind. Sie werden an bestimmte Stellen ausgeführt, wobei sie eine Schnittstelle für Input-Daten und Output-Daten besitzen. Auf diese Weise lassen sich Prozesse bzw. Arten der Datenermittlung „customizen“, also an individuelle Kundenbedürfnisse anpassen. Hier die einzelnen „ac“-Prozeduren für die einzelnen Schritte :

• Grundpreis-Ermittlung : „_ac_om_GetBasicPrices“ (s.a. „Settings“-Eintrag „Fire_ac_om_GetBasicPrices“)
• Staffelpreis-Ermittlung : „_ac_om_GetGraduatedPrices“ (s.a. „Settings“-Eintrag „Fire_ac_om_GetGraduatedPrices“)
• Surcharge-Ermittlung : „_ac_om_GetSurcharges“ (s.a. „Settings“-Eintrag „Fire_ac_om_GetSurcharges“)
• Preis-Berechnung : „_ac_om_ComputePrices“ (s.a. „Settings“-Eintrag „Fire_ac_om_ComputePrices“)

Grundsätzliches zu „Surcharges“ :

1. Der „dStore“ versteht „Surcharges“ („Aufschläge“) als Prinzip, um zusätzlich entstehende Kosten oder aber Formen von Rabatten abzubilden - diese können sowohl relativ (also prozentual) als auch absolut angegeben werden (siehe om_GetSurchargeTypes_Ad). Rabatte zeichnen sich einfach dadurch aus, daß die Kosten mit negativem Vorzeichen behaftet sind.

2. Mögliche „Surcharges“ bei der Preisermittlung für Auftrags-Positionen (→ om_GetPrices_Pu) werden aus den Tabellen „PersonSurcharges“ (für Personen) und „GroupSourcharges“ (für Gruppen) ermittelt, sofern nicht „CampaignSurchargesEnabled“ auf „1“ konfiguriert ist (s.o.). „Surcharges“ sind in diesem Kontext immer für bestimmte Elemente des Artikelbaums definiert, wobei diese sich immer auf die NACHFOLGER übertragen und nicht - wie bei den Artikeleigenschaften - auf die „ERBEN“ (d.h. hier wird die „Predecessor“-Spalte aus „TreeView“ herangezogen und nicht die „InheritsFrom“-Spalte) !

Es gelten hierbei folgende Prioritäten:

• Direkt für ein Element des Artikelbaums definierte „Surcharges“ haben Vorrang vor hinterlegten „Surcharges“ zum Vorgänger-Element (analoges Prinzip zur Vererbung von Artikel-Eigenschaften).
• „Surcharges“, die direkt einer Person zugewiesen sind, haben Vorrang vor „Surcharges“, die für eine Gruppe, der die Person angehört, hinterlegt sind.
• Falls für den Auftraggeber „GroupSurcharges“ in Frage kommen, und die Person in MEHREREN Gruppen ist, zu denen „Surcharges“ hinterlegt sind, wird die Gruppe mit der höchsten Priorität gewählt - das ist die Gruppe mit der kleinsten „SortNo“ in der Rückgabemenge von pm_GetGroups_Ad mit entsprechend angegebener „PersonID“.

3. Es gibt seit Version 6.0.2 auch das Konzept von „Surcharges“ für einen gesamten Warenkorb bzw. Auftrag (→ om_GetTrolleySurcharges_Pu, om_GetOrderSurcharges_Ad). Dabei handelt es sich um Dinge wie Versandkosten, Skonti, Guthabenverrechnung oder ein (Gesamt-)Auftrags-Rabatt. Letzterer kann zwar auch in den meisten Fällen als Rabatt für alle Auftrags-Positionen abgebildet werden (s. 2.), aber bei absoluten Rabatten ist dies steuerlich nicht korrekt, falls unterschiedliche Steuersätze im Auftrag vorkommen !

Hinweise zur Rabatt-Berechnung im Falle von Verkaufsaktionen :

1. Sofern durch „CampaignSurchargesEnabled“ wie oben beschrieben evtl. Rabatte durch Verkaufs-Aktionen beachtet werden, spielen die Parameter „PersonID“, „PaymentTypeID“ und „ShippingTypeID“ eine Rolle. Es gibt Aktionen, die als Bedingung eine bestimmte Zahlungs-und/oder Versandart erfordern bzw. ausschließen oder bei denen der Auftraggeber einer bestimmten (Personen-)Gruppe angehören muß. Sobald dem Aufrufer der Auftraggeber und/oder die Zahlungs- und/oder Versandart bekannt ist, sollte er/sie über „PersonID“ bzw. „PaymentTypeID“ bzw. „ShippingTypeID“ angegeben werden, weil sonst JEDE Aktion, die eine Personengruppen- bzw. Zahlungsart- bzw. Versandart-Bedingung besitzt, HERAUSgefiltert wird, genauer :

• Ist „PersonID“ unbekannt, werden Aktionen mit einer Personengruppen-Bedingung auf jeden Fall NICHT beachtet
• Ist „PaymentTypeID“ unbekannt, fliegen die Aktionen mit einer Zahlungsart-Bedingung garantiert heraus
• Ist „ShippingTypeID“ unbekannt, scheiden die „Campaigns“ mit einer Versandart-Bedingung aus.

2. Wenn für einen Artikel ein Rabatt aufgrund eines oder mehrerer Bundle gewährt wird, werden mögliche „SurchargeBenefits“ (prozentuale oder absolute Rabatte aufgrund von Artikel-Bedingungen) ignoriert, denn : Kommt durch andere Verkaufs-Aktionen ein BESSERER Rabatt zustande, müßte der entsprechende Artikel aus dem Bundle entfernt werden, was zur Folge hätte, daß ANDERE Artikel (die zum betroffenen Bundle gehören) dann KEINEN Rabatt mehr bekommen, was insgesamt dann aber für den Kunden schlechter sein könnte ! Es würde also ein „Domino-Effekt“ entstehen, der sich signifikant (negativ) auf die Performance auswirkt.

Anmerkung zum Parameter „ComputeSum“ :

Möchte man zusätzlich eine Summe berechnet haben, setzt man den Parameter „ComputeSum“ auf „1“. Dann hat das Ergebnis noch eine weitere Zeile (am Ende), mit den entsprechenden Summen - bis auf folgende Ausnahmen :

• „NodeID“ und „TreeNodeID“ enthalten den Wert „-1“
• „TaxesMultiplier“ enthält den Wert <Summe von „UnitGrossPrice“> / <Summe von „UnitNetPrice“>
• „RelativeSurcharge“ wird nach folgender Formel berechnet :

<Summe von AbsoluteUnitNetSurcharge> * 100 / (<Summe von UnitNetPrice> - <Summe von AbsoluteUnitNetSurcharge>)

• In den Spalten „SurchargeTypeID“, „SurchargeValue“ und „PriceNodeCharacteristicID“ steht „NULL“

Anmerkung zu den Parametern „UniqueID“ und „DeliveryPersonID“ :

Für spätere Erweiterungen bzw. für eine evtl. individuelle Implementierung innerhalb der Preisermittlung (→ z.B. „_ac_om_GetBasicPrices“ oder „_ac_om_GetSurcharges“) kann es wichtig sein, daß der „Besucher“, der die „Preisanfrage“ durch diese Prozedur hier stellt, ein Rolle spielt. Daher gibt es (optional) die Möglichkeit, diesen über den Parameter „UniqueID“ zu referenzieren.
Analog kann über „DeliveryPersonID“ optional die ID einer Lieferanschrift übergeben werden, um z.B. eine „Brutto=Netto“-Berechnung im Falle einer Lieferung an ein Land außerhalb der EU (unter der Annahme, daß die Ware aus einem EU-Land heraus geliefert wird) zu ermöglichen.
Hinweis : Letzteres ist nämlich KEIN Standard-Verhalten, sondern muß in „_ac_om_GetBasicPrices“ bzw. „_ac_om_ComputePrices“ implementiert werden !

Anmerkungen zum Parameter „GetPricePerSingleNodeID“ :

1.) Wird für „GetPricePerSingleNodeID“ der Wert „1“ angegeben, werden die in „NodeIDs“ gegebenen Elemente separat betrachtet. Dies bedeutet insbesondere, daß Rabatte über Verkaufs-Aktionen (s. Hinweis in Punkt 3 im obigen Preisermittlungs-Algorithmus), die durch eine Menge von einer bestimmten Kombination von „TreeNodeIDs“ oder deren Eigenschaften abhängig sind, NICHT in den zu ermittelnden Preis einfließen.

2.) Wichtige Einschränkung : Ist „GetPricePerSingleNodeID = 1“, müssen ALLE „Quantity“-Werte (→ „Quantities“) „1“ sein (oder alternativ einfach „Quantities = NULL“ angeben, dann wird automatisch „1“ als „Quantity“ für jedes Artikel-Element gewählt) - andernfalls kommt es zu einem Fehler !

3.) Beispiel : Sollte es eine Verkaufsaktion geben, die Artikel mit der Eigenschaft „schwarz“ zum Merkmal „Farbe“ um 10 Prozent reduziert, wenn mindestens 1 Artikel gekauft wird, der zum Merkmal „Farbe“ den Wert „blau“ besitzt, würde dieser Rabatt NICHT in die Preisermittlung einfließen, wenn „GetPricePerSingleNodeID = 1“ ist.

Anmerkung zur Rückgabespalte „QuantityPerBundleItemSetIDList“ :

Durch ein „,“ getrennte Liste von Listen, deren Werte wiederum durch „&“ getrennt sind, und ein Wert die Form <Menge>x<BundleItemSetID> hat. Dies besagt jeweils, wieviel (<Menge>) von „Quantity“ der „TreeNodeID“ zu der „<BundleItemSetID>“ des Bundles gehört. Die zugehörige „BenefitID“ ergibt sich automatisch, weil eine „ItemSetID“ nur einer „BenefitID“ zugeordnet werden darf. Alle Datensätze haben die gleiche Anzahl Elemente (sowohl die Liste von Listen als auch die „<Menge>x<ItemSetID>“-Liste). Ist „TreeNodeID“ kein Teil eines Bundles, wird als „<Menge>“ eben „0“ eingetragen.
Hinweis : Die „<Menge>“-Werte haben pro Element in der Liste dieselbe Anzahl Stellen (einige sind also ggf. mit „0“en zu Beginn aufgefüllt).

(parameterunabängige Sortierung)

• NodeID (aufsteigend)

Die Prozedur hat keine Output-Parameter.

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

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

• om_GetPrices_Pu im Engine Playground öffnen

Unformatierte Ausgabe:

curl -X GET  'http://<partner>-<project>.dstore.de/default/engine/om_GetPrices_Pu?NodeIDs=<value>'

Mit xmllint ⁶⁾ formatierte Ausgabe:

curl -X GET  'http://<partner>-<project>.dstore.de/default/engine/om_GetPrices_Pu?NodeIDs=<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_GetPrices_Pu',
		array(
			'NodeIDs' => '<value>',
			// 'Quantities' => NULL,
			// 'PersonID' => NULL,
			// 'CurrencyID' => NULL,
			// 'IsTreeNodeID' => 1,
			// 'PriceNodeCharacteristicID' => NULL,
			// 'ComputeSum' => 0,
			// 'UniqueID' => NULL,
			// 'GetAdditionalPriceInfo' => 0,
			// 'DeliveryPersonID' => NULL,
			// 'GetPricePerSingleNodeID' => 0,
			// 'PaymentTypeID' => NULL,
			// 'ShippingTypeID' => NULL
		)
);
 
$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_GetPrices_Pu">
			<Parameters>
				<Parameter Name="NodeIDs"><!-- varchar value --></Parameter>
				<!-- <Parameter Name="Quantities">NULL</Parameter> -->
				<!-- <Parameter Name="PersonID">NULL</Parameter> -->
				<!-- <Parameter Name="CurrencyID">NULL</Parameter> -->
				<!-- <Parameter Name="IsTreeNodeID">1</Parameter> -->
				<!-- <Parameter Name="PriceNodeCharacteristicID">NULL</Parameter> -->
				<!-- <Parameter Name="ComputeSum">0</Parameter> -->
				<!-- <Parameter Name="UniqueID">NULL</Parameter> -->
				<!-- <Parameter Name="GetAdditionalPriceInfo">0</Parameter> -->
				<!-- <Parameter Name="DeliveryPersonID">NULL</Parameter> -->
				<!-- <Parameter Name="GetPricePerSingleNodeID">0</Parameter> -->
				<!-- <Parameter Name="PaymentTypeID">NULL</Parameter> -->
				<!-- <Parameter Name="ShippingTypeID">NULL</Parameter> -->
			</Parameters>
		</Procedure>
	</Batch>
</ListOfBatches>