Ändert den Status von Auftragspositionen.

Es darf natürlich nicht jeder Benutzer irgendwelche Positionen von einem Status in irgendeinen anderen Status ändern, sondern es muß eine entsprechende Regel in „OrderStateRules“ (s. om_GetOrderStateRules_Ad) konfiguriert sein. Dort wird also immer nachgeschaut, ob auch wirklich die benötigten Berechtigungen für die Änderungen vorhanden sind. Sollte es dabei Probleme geben, wird KEINE Position geändert und es gibt den Fehler „-340“ !
Da die Berechtigungen von einer „PaymentForShippingID“ (d.h. einer Zahl-/Versandart-Kombination) abhängen, müssen wir zu den Aufträgen der betroffenen Positionen die Zahlart und die Versandart ermitteln. Die sich hieraus ergebenden Kombinationen müssen aktuell auch in „PaymentForShipping“ konfiguriert sein, sonst können wir die Berechtigungs-Überprüfung ja nicht durchführen ! Kann eine Zahl-/Versandart-Kombination nicht ermittelt werden, brechen wir ebenfalls ab, und zwar mit dem Fehler „-330“ !

Allgemeiner Hinweis zum feature der „TRI-Trigger“ :

U.U. möchte man, daß durch das Ändern eines Status irgendwelche Aktionen ausgelöst werden (Überprüfungen, Benachrichtigungen etc.). Zu diesem Zweck gibt es die Möglichkeit, einen sogenannten „TRI-Trigger“ an den Status („OrderStateID“) zu koppeln. Näheres dazu ist dem Parameter „ChangeOrderStateTriggerID“ von om_ModifyOrderStates_Ad zu entnehmen.

Dem Trigger (bzw. wenn entsprechend konfiguriert : der „Custom“-Prozedur, die innerhalb des Triggers dann aufgerufen wird - s. Rückgabespalte „ExecuteProcedureName“ von mi_GetTRITrigger_Ad) stehen neben der „OrderStateID“ noch weitere Daten zur Verfügung :
Und zwar werden die vom Status-Wechsel betroffenen „OrderContentID“s zusammen mit der Information, in welchem Status sie jeweils VOR dem Wechsel waren, in der Tabelle „dstoreifin.dbo._ac_ChangeOrderState“ (in den beiden Spalten „OrderContentID“ und „PreviousOrderStateID“) übergeben.

ACHTUNG : Wenn in dem Trigger z.B. der Status einiger Positionen einfach „weitergesetzt“ wird, d.h. wieder om_ChangeOrderState_Ad aufgerufen wird, und dazu die „OrderContentID“s in „tempdb.dbo.OneID“ übergeben werden, sind die evtl. ursprünglich übergebenen IDs in „tempdb.dbo.OneID“ natürlich „futsch“ !

Anmerkungen zum Parameter „AcceptNegativeStock“:

Sind das „AvailabilityManagement“ in „Settings“ aktiviert (d.h. ist der Wert zu diesem Schlüssel „1“), und gehört der neue Status (→ „OrderStateID“) der Kategorie „1“ an, wird zu jedem Artikel, dessen alte „OrderStateID“ der zugehörigen Auftragsposition NICHT der Kategorie „1“ angehört, die noch vorhandene Menge (Eigenschaft zum Merkmal mit „NodeCharacteristicID = 3“) um die bestellte Anzahl reduziert. Dies geschieht nur bei Artikeln, zu denen es das Attribut „Menge“ überhaupt gibt. Bei einer Änderung von einem Status der Kategorie „1“ in einen Status, der nicht der Kategorie „1“ zugeordnet ist, werden entsprechende Mengen gutgeschrieben.
Falls eine neu berechnete Menge negativ sein sollte, wird der Vorgang im Falle „AcceptNegativeStock = 0“ abgebrochen !
Andernfalls wird die „Verfügbarkeit“ (Eigenschaft zum Merkmal mit der ID „9“) des betroffenen Artikel-Elementes auf „Nicht lieferbar“ (interne „ValueID = -1“) gesetzt.
ACHTUNG :Wenn ein Artikel vor dem Aufruf die Eigenschaft „Nicht lieferbar“ hatte, durch diese Prozedur aber Mengen gutgeschrieben werden, so daß der Bestand auf einen Wert steigt, der den Artikel wieder „lieferbar“ macht (z.B. wenn die Mengen-Angabe wieder positiv ist), wird die Eigenschaft zum Merkmal „Verfügbarkeit“ NICHT aktualisiert, d.h. das Produkt BLEIBT „Nicht lieferbar“ !

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_ChangeOrderState_Ad im Engine Playground öffnen

Unformatierte Ausgabe:

curl -X POST  'http://<partner>-<project>.dstore.de/default/engine/om_ChangeOrderState_Ad?OrderContentIDs=<value>&OrderStateID=<value>'

Mit xmllint ³⁾ formatierte Ausgabe:

curl -X POST  'http://<partner>-<project>.dstore.de/default/engine/om_ChangeOrderState_Ad?OrderContentIDs=<value>&OrderStateID=<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_ChangeOrderState_Ad',
		array(
			'OrderContentIDs' => '<value>',
			'OrderStateID' => <value>,
			// 'IsOrderID' => 0,
			// 'AcceptNegativeStock' => 1,
			// 'SelectDeniedOrders' => 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_ChangeOrderState_Ad">
			<Parameters>
				<Parameter Name="OrderContentIDs"><!-- varchar value --></Parameter>
				<Parameter Name="OrderStateID"><!-- tinyint value --></Parameter>
				<!-- <Parameter Name="IsOrderID">0</Parameter> -->
				<!-- <Parameter Name="AcceptNegativeStock">1</Parameter> -->
				<!-- <Parameter Name="SelectDeniedOrders">0</Parameter> -->
			</Parameters>
		</Procedure>
	</Batch>
</ListOfBatches>