Hallo zusammen,
ich habe einen Service SRV00299 bei dem der User keine Mails vom Bestellprozess bekommen soll. Bei allen anderen Bestellungen soll eine Mail versendet werden.
Über die Konformitätsregel habe ich versucht eine Ausnahme zu erstellen:
z.B. Confirm creation of new Order to Requestor
Art der Bedingung
Anlegen eines Objektes
Hauptdatendefinition.Service (Service)
Nicht gleich
SRV00299 - xxxxxxxxxx
die Regel scheint das System nicht zu interessieren und es schickt die Mail trotzdem raus. Hat jemand etwas ähnliches erlebt und eine Lösung für dieses Problem?
Vielen Dank
Konformitätsregel Bestellprozess
-
- Posts: 19
- Joined: 30. Apr 2021, 11:37
- Contact:
Re: Konformitätsregel Bestellprozess
Hatte diese Woche schon das gleiche Problem und ein Ticket dazu bei M42 eröffnet. Sie untersuchen es, Antwort noch ausstehend. Wenn ich was dazu höre, gebe ich Bescheid
-
- Posts: 19
- Joined: 30. Apr 2021, 11:37
- Contact:
Re: Konformitätsregel Bestellprozess
Vielen Dank, das wäre super!
-
- Posts: 19
- Joined: 30. Apr 2021, 11:37
- Contact:
Re: Konformitätsregel Bestellprozess
Gibt es hier schon neue Erkenntnisse? Vielen Dank
Re: Konformitätsregel Bestellprozess
Ja, gibt es seit wenigen Tagen. Ich hatte aber noch keine Zeit es zu testen, deswegen auch noch kein Feedback hier.
Anbei mal die Infos der Matrix dazu
".....die Relation, welche Sie nutzen, ist bei Bestellungen niemals gefüllt.
Diese Relation wird für Konfigurationsformulare in einem Service genutzt. (Create Task, Create Change etc, wann immer Sie im auf der Seite "Bereitstellung" vom Servicedialog) eine extra Formular ausfüllen können.
D.h. diese Bedingung ist immer "wahr" und wird triggern, womit es kein Produktfehler ist.
Generell können Sie in den Bedingungen einer CoRu nicht auf Relationen mit der N Seite prüfen.
(Konstrukt einer Bestellung: Bestellungen > mehrere Buchungen > ein Service pro Buchung.)
Lösungsweg 1:
Eine Information am Bestellantrag schaffen, auf den Sie in der CoRu triggern können.
Also im Bereitstellungsworkflow des speziellen Service entsprechend ein Update Object / Updatefragment auf die entsprechende Tabelle des Bestellantrags setzen, auf den man in einer CoRu prüfen kann. Eigenes Boolfeld oder einen speziellen String in das SPSSelfServiceOrderItemClassBase.Reason Feld. (Reason wird an sich nur gesetzt, wenn die Bestellung abgelegt wird.)
Lösungsweg 2:
Anstatt in den Conditions können Sie auch einfach verhindern, dass ein "Recipient" übergeben wird. In der "Inform Responsibles when a new Ticket was Created" Coru finden Sie ein entsprechendes Beispiel.
In der Definition der Mail Empfänger wird eine ASQL Expression genutzt und nur dann eine Mail zusenden, wenn NotifyResponsible = 1 ist. Ansonsten liefert der ASQL String einfach keine User ID. Eine ähnliches Konzept könnten Sie im Falle der Order mit einem verschachtelten Subquery erreichen > Subquery auf SPSSelfServiceOrderItemClassBase und nur den Recipient rausgeben when Exists(subquery auf die Buchungen der Order mit der entsprechenden Service ID in der where Clause Bereich.)
Beides wird funktionieren, Lösungsweg 1 ist einfacher (auch für einen Kunden zu verstehen), allerdings muss man Workflow, CoRu und das Schema eventuell anpassen.
Lösungsweg 2 muss man nur 2 Compliance Rules anpassen, erfordert jedoch etwas mehr Erfahrung mit ASQL."
Anbei mal die Infos der Matrix dazu
".....die Relation, welche Sie nutzen, ist bei Bestellungen niemals gefüllt.
Diese Relation wird für Konfigurationsformulare in einem Service genutzt. (Create Task, Create Change etc, wann immer Sie im auf der Seite "Bereitstellung" vom Servicedialog) eine extra Formular ausfüllen können.
D.h. diese Bedingung ist immer "wahr" und wird triggern, womit es kein Produktfehler ist.
Generell können Sie in den Bedingungen einer CoRu nicht auf Relationen mit der N Seite prüfen.
(Konstrukt einer Bestellung: Bestellungen > mehrere Buchungen > ein Service pro Buchung.)
Lösungsweg 1:
Eine Information am Bestellantrag schaffen, auf den Sie in der CoRu triggern können.
Also im Bereitstellungsworkflow des speziellen Service entsprechend ein Update Object / Updatefragment auf die entsprechende Tabelle des Bestellantrags setzen, auf den man in einer CoRu prüfen kann. Eigenes Boolfeld oder einen speziellen String in das SPSSelfServiceOrderItemClassBase.Reason Feld. (Reason wird an sich nur gesetzt, wenn die Bestellung abgelegt wird.)
Lösungsweg 2:
Anstatt in den Conditions können Sie auch einfach verhindern, dass ein "Recipient" übergeben wird. In der "Inform Responsibles when a new Ticket was Created" Coru finden Sie ein entsprechendes Beispiel.
In der Definition der Mail Empfänger wird eine ASQL Expression genutzt und nur dann eine Mail zusenden, wenn NotifyResponsible = 1 ist. Ansonsten liefert der ASQL String einfach keine User ID. Eine ähnliches Konzept könnten Sie im Falle der Order mit einem verschachtelten Subquery erreichen > Subquery auf SPSSelfServiceOrderItemClassBase und nur den Recipient rausgeben when Exists(subquery auf die Buchungen der Order mit der entsprechenden Service ID in der where Clause Bereich.)
Beides wird funktionieren, Lösungsweg 1 ist einfacher (auch für einen Kunden zu verstehen), allerdings muss man Workflow, CoRu und das Schema eventuell anpassen.
Lösungsweg 2 muss man nur 2 Compliance Rules anpassen, erfordert jedoch etwas mehr Erfahrung mit ASQL."
-
- Posts: 19
- Joined: 30. Apr 2021, 11:37
- Contact:
Re: Konformitätsregel Bestellprozess
Vielen Dank dafür! Ich gebe Feedback, sobald ich dazu komme.
Who is online
Users browsing this forum: No registered users and 1 guest