Benutzer-Werkzeuge

Webseiten-Werkzeuge


engine:procedures:om_getprices_pu

om_GetPrices_Pu

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).

HTTP-MethodGET
HTTP-AuthOptional
Tags
Engine-Kategorieorder management
Engine-TypDaten-Ermittlung
Letzte Aktualisierung7.0.7 (2015-01-29)

Parameter

Name 1) Standard-Wert Beschreibung 2) SQL-Datentyp3) ab Version
NodeIDs Eine Liste von IDs (durch das '¶'-Zeichen getrennt) von Artikel-Elementen bzw. Elementen des Artikelbaums (je nach „IsTreeNodeID“), zu denen jeweils der Verkaufspreis ermittelt werden soll
varchar(255)3.5.0
QuantitiesNULL Zu „NodeIDs“ korrespondierende Liste von Mengenangaben für das jeweilige Element. Bei „NULL“ wird die Menge „1“ für jedes Element gewählt. Falls „GetPricePerSingleNodeID = 1“ ist, müssen alle Mengeangaben „1“ sein (bzw. muß hier „NULL“ stehen) !
varchar(255)3.5.0
PersonIDNULL ID einer Person. Wenn angegeben, werden bei der Preisermittlung evtl. vorhandene „Surcharges“ (Rabatte/Aufschläge) für diese Person oder für die Gruppen, in denen sich die Person befindet, berücksichtigt.
integer3.5.0
CurrencyIDNULL ID einer Währung („UnitID“ aus der Kategorie „Währung“), in der die Preise ausgegeben werden sollen
tinyint3.5.0
IsTreeNodeID1 Um was handelt es sich bei „NodeIDs“ ?
„0“ : Bei den angegebenen IDs handelt es sich um Artikel-Elemente („NodeID“s aus der Tabelle „dStore“)
„1“ : Die IDs sind Elemente des Artikelbaums („TreeNodeID“s aus „TreeView“)
bit3.5.0
PriceNodeCharacteristicIDNULL ID eines Merkmals. Die Preisermittlung läuft i.d.R. über die rekursiven Merkmale „Verkaufspreis…“. Möchte man aber z.B. sowohl Einzel- als auch Großhandel über denselben Artikelstamm abwickeln, kann man hierdurch ein anderes „Preis-Merkmal“ angeben.
smallint3.5.5
ComputeSum0 „1“ angeben, um in der Rückgabemenge eine weitere „Ergebnis-Zeile“ (die LETZTE Zeile, unabhängig der Sortierung) zu erhalten, die „Summen“ enthält. Für einige Spalten kann natürlich keine „Summe“ gebildet werden, siehe Anmerkung in der Beschreibung !
bit3.5.13
UniqueIDNULL Eindeutige ID eines Besuchers (aus „Visitors“). Hintergrund : Für eine evtl. individuelle Implementierung innerhalb der Preisermittlung (→ z.B. „_ac_om_GetBasicPrices“) wird der Besucher, der die „Preisanfrage“ stellt, benötigt.
varchar(100)5.5.0
GetAdditionalPriceInfo0 „1“ angeben, damit die Rückgabespalten „SurchargeReason“, „SurchargeGeneratedByCampIDs“ und „QuantityPerBundleItemSetIDList“ gefüllt werden (sofern ein Wert vorhanden ist)
bit5.5.0
DeliveryPersonIDNULL ID einer Person, an die die Ware geliefert werden soll. Falls angegeben, wird diese ID an die interne Preis-Ermittlung weitergereicht (derzeit ohne Funktionalität), um z.B. in „_ac_om_GetBasicPrices“ verwendet werden zu können (s. Beschreibung).
integer6.0.0
GetPricePerSingleNodeID0 „1“ angeben, um Einzelpreise zu ermitteln und um zu verhindern, daß der Preis eines Artikels von einem anderen Artikel beeinflußt wird (wie bspw. bei Verkaufs-Aktionen der Art „Kaufe mind. 1 Artikel 'in rot', erhalte 10% auf alle 'blauen Produkte'“)
bit6.5.1
PaymentTypeIDNULL ID einer Zahlungsart, mit der voraussichtlich der Auftrag platziert wird - relevant für evtl. Reduzierungen von Artikelpreisen durch Verkaufs-Aktionen mit Bedingungen, die von der Zahlungsart abhängen
smallint6.5.1
ShippingTypeIDNULL ID einer Versandart, mit der voraussichtlich der Auftrag platziert wird - relevant für evtl. Reduzierungen von Artikelpreisen durch Verkaufs-Aktionen mit Bedingungen, die von der Versandart abhängen
tinyint6.5.1

Rückgabe

(parameterunabhängig)

Spaltenname Beschreibung SQL-Datentyp4) ab Version
NodeIDID eines Artikel-Elementes, zu dem der Verkaufspreis ermittelt wurde (also entweder ein Element, das in „NodeIDs“ übergeben wurde, oder ein Element, das zu einer „TreeNodeID“ korrespondiert, die in „NodeIDs“ angegeben wurde)
integer3.5.0
TreeNodeIDID eines zur „NodeID“ korrespondierenden Elementes im Artikelbaum, das zur Preisermittlung herangezogen wurde bzw. (falls „IsTreeNodeID = 1“) eine ID, die in „NodeIDs“ übergeben wurde
integer5.0.1
QuantityWieviel von dem Artikel bestellt werden soll. Hier steht also entweder die Zahl, die in „Quantities“ angegeben wurde, oder „1“.
integer3.5.0
UnitNettoPriceNetto-Preis von „NodeID“, wenn man den Artikel EINMAL bestellt (Englischer Spaltenname ist NICHT korrekt, NICHT mehr verwenden !)
money3.5.0
UnitNetPriceNetto-Preis von „NodeID“, wenn man den Artikel EINMAL bestellt
money5.0.1
PreciseUnitNetPriceExakter (intern gespeicherter) Wert für „UnitNetPrice“
decimal(16,4)5.0.1
UnitBruttoPriceBrutto-Preis von „NodeID“, wenn man den Artikel EINMAL bestellt (Englischer Spaltenname ist NICHT korrekt, NICHT mehr verwenden !)
money3.5.0
UnitGrossPriceBrutto-Preis von „NodeID“, wenn man den Artikel EINMAL bestellt
money5.0.1
PreciseUnitGrossPriceExakter (intern gespeicherter) Wert für „UnitGrossPrice“
decimal(16,4)5.0.1
TotalNettoPriceNetto-Preis von „NodeID“, wenn man den Artikel „Quantity-Mal“ bestellt (Englischer Spaltenname ist NICHT korrekt, NICHT mehr verwenden !)
money3.5.0
TotalNetPriceNetto-Preis von „NodeID“, wenn man den Artikel „Quantity-Mal“ bestellt
money5.0.1
PreciseTotalNetPriceExakter (intern gespeicherter) Wert für „TotalNetPrice“
decimal(16,4)5.0.1
TotalBruttoPriceBrutto-Preis von „NodeID“, wenn man den Artikel „Quantity-Mal“ bestellt (Englischer Spaltenname ist NICHT korrekt, NICHT mehr verwenden !)
money3.5.0
TotalGrossPriceBrutto-Preis von „NodeID“, wenn man den Artikel „Quantity-Mal“ bestellt
money5.0.1
PreciseTotalGrossPriceExakter (intern gespeicherter) Wert für „TotalGrossPrice“
decimal(16,4)5.0.1
TaxesMultiplierMehrwertsteuer als „Multiplikator“. D.h. beträgt die Mehrwertsteuer z.B. „16 %“, steht hier der Wert „1.16“.
decimal(16,6)5.0.1
RelativeSurchargeRelativer Rabatt/Aufschlag in Prozent (der in den Preisen bereits enthalten ist !). Ein negativer Wert bedeutet einen Rabatt, sonst beinhaltet der Verkaufspreis einen Aufschlag.
decimal(16,6)3.5.0
AbsoluteUnitNettoSurchargeAbsoluter Rabatt/Aufschlag, der in „UnitNetPrice“ bereits ENTHALTEN ist (Englischer Spaltenname ist NICHT korrekt, NICHT mehr verwenden !)
money3.5.0
AbsoluteUnitNetSurchargeAbsoluter Rabatt/Aufschlag, der in „UnitNetPrice“ bereits ENTHALTEN ist
money5.0.1
PreciseAbsUnitNetSurchargeExakter (intern gespeicherter) Wert für „AbsoluteUnitNetSurcharge“
decimal(16,4)5.0.1
AbsoluteUnitBruttoSurchargeAbsoluter Rabatt/Aufschlag, der in „UnitGrossPrice“ bereits ENTHALTEN ist (Englischer Spaltenname ist NICHT korrekt, NICHT mehr verwenden !)
money3.5.0
AbsoluteUnitGrossSurchargeAbsoluter Rabatt/Aufschlag, der in „UnitGrossPrice“ bereits ENTHALTEN ist
money5.0.1
PreciseAbsUnitGrossSurchargeExakter (intern gespeicherter) Wert für „AbsoluteUnitGrossSurcharge“
decimal(16,4)5.0.1
AbsoluteTotalNettoSurchargeAbsoluter Rabatt/Aufschlag, der im „TotalNetPrice“ bereits ENTHALTEN ist (Englischer Spaltenname ist NICHT korrekt, NICHT mehr verwenden !)
money3.5.0
AbsoluteTotalNetSurchargeAbsoluter Rabatt/Aufschlag, der im „TotalNetPrice“ bereits ENTHALTEN ist
money5.0.1
PreciseAbsTotalNetSurchargeExakter (intern gespeicherter) Wert für „AbsoluteTotalNetSurcharge“
decimal(16,4)5.0.1
AbsoluteTotalBruttoSurchargeAbsoluter Rabatt/Aufschlag, der im „TotalGrossPrice“ bereits ENTHALTEN ist (Englischer Spaltenname ist NICHT korrekt, NICHT mehr verwenden !)
money3.5.0
AbsoluteTotalGrossSurchargeAbsoluter Rabatt/Aufschlag, der im „TotalGrossPrice“ bereits ENTHALTEN ist
money5.0.1
PreciseAbsTotalGrossSurchargeExakter (intern gespeicherter) Wert für „AbsoluteTotalGrossSurcharge“
decimal(16,4)5.0.1
SurchargeTypeIDID einer Preis-Aufschlags/Rabatt-Art, die ermittelt und bei der Preis-Ermittlung angewandt wurde
smallint3.5.0
SurchargeValueDer Wert des Aufschlags bzw. Rabattes, der verwendet wurde. Ist die „SurchargeTypeID“ relativ definiert, entspricht dieser Wert dem in „RelativeSurcharge“, andernfalls dem Wert in „AbsoluteUnitNetSurcharge“ bzw. „AbsoluteUnitGrossSurcharge“
decimal(16,6)3.5.0
PriceNodeCharacteristicIDMerkmal-ID, die den Preis bestimmt hat (genauer : die Eigenschaft von „TreeNodeID“ zu diesem Merkmal hat den Preis bestimmt)
smallint4.0.7
SurchargeReason„Grund“ für einen evtl. vorhandenen Rabatt (z.B. ein „Aktionsname“, der letztlich von der individuellen Rabatt-Ermittlung durch „_ac_om_GetSurcharges“ stammt). Immer „NULL“, wenn „GetAdditionalPriceInfo = 0“ ist !
varchar(100)5.5.0
SurchargeGeneratedByCampIDsListe von „CampaignID“s der Verkaufsaktionen, die zur Rabattierung der Position geführt haben. Immer „NULL“, wenn „GetAdditionalPriceInfo = 0“ ist oder keine Rabattierung vorliegt !
varchar(255)6.5.1
QuantityPerBundleItemSetIDListDurch 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 „<ItemSetID>“ des Bundles gehört.
varchar(255)7.0.6
Sortierung der Rückgabe

(parameterunabängige Sortierung)

  • NodeID (aufsteigend)

Output-Parameter

Die Prozedur hat keine Output-Parameter.

Mögliche Return-Codes

Code Beschreibung Quelle 5)
-1204Fehlender oder falscher Eintrag in CampaignSettingsnur indirekt
-621Fehlender oder falscher Eintrag in PersonTypeSettingsnur indirekt
-599Lizenz ist ungültig oder abgelaufennur indirekt
-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
-550Fehlender oder falscher Eintrag in Settingsnur indirekt
-540Falsches Formatnur 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
-503Fehlerhafte Daten in einer Tabelle - genauere Fehlermeldung auf der Standardausgabenur indirekt
-502Die Parameter-Werte der Prozedur können nicht verarbeitet werden (kein passendes Trennzeichen)nur indirekt
-500Falsche Parameterdirekt und indirekt
-333Ein benötigter Steuersatz ist nicht bekannt oder konnte nicht ermittelt werdennur indirekt
-283Der Benutzer hat keine Berechtigung, Eigenschaften zu diesem(n) Merkmal(en) zu ermittelnnur indirekt
-221Es konnte kein rekursives Merkmal mit der Standardwährung als Einheit ermittelt werdennur indirekt
-120Der Benutzer hat keine Berechtigung für das (die) Element(e)nur indirekt
-110Das (die) Element(e) ist (sind) nicht vorhandennur 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-29„Start-/Finish-Procedure“-Logik eingebaut, s. Ticket #3670
7.0.6 2014-06-231. Neue Rückgabespalte „QuantityPerBundleItemSetIDList“
2. Aktualisierung der Doku zur Preisermittlung [wg. Bundle-Preis]
7.0.2 2013-08-29Doku-Hinweis bzgl. Parameter „PersonID“, der nun auch relevant für Verkaufsaktionen ist
6.5.1 2012-11-021. Neue Rückgabespalte „SurchargeGeneratedByCampIDs“
2. Neue Parameter „GetPricePerSingleNodeID“, „PaymentTypeID“ und „ShippingTypeID“
6.5.0 2012-09-17Hinweis in der Doku auf den neuen „Settings“-Eintrag „CampaignSurchargesEnabled“ und die Auswirkung auf die Preis-
Ermittlung
6.0.2 2011-06-08Keine Änderung, lediglich eine Anpassung der Doku bzgl. „Surcharges“ (zu diesem Thema gab es Änderungen)
6.0.0 2010-03-26Neuer Parameter „DeliveryPersonID“
5.5.0 2008-01-071. Neue Parameter „UniqueID“ und „GetAdditionalPriceInfo“
2. Neue Rückgabespalte „SurchargeReason“
3. Ausgabe an die Standard-Ausgabe [via „print“] im Fehler-Fall „-500“, die nähere Informationen über die Ursache enthält
5.0.1 2005-03-291. Interner Aufruf von „_om_GetPrices“ wurde komplett umgestellt
2. Neuer „Settings“-Eintrag „AlwaysConsiderGraduatedPrices“
3. Neue Rückgabespalten
4. Änderungen für Werte bestimmter Spalten in der „Summen-Zeile“ [also falls „ComputeSum = 1“]
5.0.0 2004-12-21Nur Änderung der Doku : Erwähnung des neuen „Settings“-Eintrags „AlwaysConsiderSurcharges“
4.0.7 2004-01-16Neue Rückgabespalte „PriceNodeCharacteristicID“
3.5.16 2002-04-25
3.5.13 2001-12-06
3.5.11 2001-09-06
3.5.5 2001-03-30
3.5.0 2000-11-23Erstmalig 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 GET  'http://<partner>-<project>.dstore.de/default/engine/om_GetPrices_Pu?NodeIDs=<value>'

Mit xmllint 6) formatierte Ausgabe:

curl -X GET  'http://<partner>-<project>.dstore.de/default/engine/om_GetPrices_Pu?NodeIDs=<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_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();
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_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>
1) Pflichtparameter sind unterstrichen
5) direkt meint „von der Prozedur selber“ und indirekt meint „von intern aufgerufenen Unterprozeduren“
6) I.d.R. auf Unix-artigen Systemen bereits installiert, Bestandteil der libxml2, siehe http://www.xmlsoft.org
engine/procedures/om_getprices_pu.txt · Zuletzt geändert: 11.01.2016 (Externe Bearbeitung)

Seiten-Werkzeuge