Zum Hauptinhalt springen

Spesenknoten

Verwende diese Workflow-Designer-Knoten, um die Geschäftslogik für Spesen an die Anforderungen Deines Unternehmens anzupassen.

Verfasst von Yokoy Team

🌐 Web | 👤 Yokoy-Admin mit Workflow Designer-Berechtigungen

🏢 Knotennutzung - Professional und Enterprise-Plan

Einige Bedingungs-, Aktivitäts- und Genehmigungsknoten sind nur in den Yokoy Professional- oder Enterprise-Plänen verfügbar. Dein Unternehmen muss über einen dieser Pläne verfügen, um diese Knoten in Deinem Workflow verwenden zu können.

Der Workflow Designer verwendet Knoten, um die Geschäftslogik festzulegen, die bei der Verarbeitung von Spesen in Yokoy angewendet wird.

Wenn Du einen Workflow erstellst, verwende diese vier Knotentypen:

  • Statusknoten: Zeigen den Status eines Dokuments an. Anders gesagt: Diese Knoten stellen interne Status in Yokoy dar (z. B. Entwurf, In Genehmigung usw.).

  • Bedingungsknoten: Stellen bedingte Klauseln dar. Es handelt sich um Wenn-Dann-Bedingungen, die auf einer bestimmten Logik basieren und entweder wahr oder falsch sind.

  • Aktivitätsknoten: Stellen Aktionen oder Aufgaben dar, die im Hintergrund in Yokoy ausgeführt werden.

  • Genehmigungsknoten: Ergänzen Aktivitätsknoten, um die Geschäftslogik eines Genehmigungsablaufs abzubilden.

Statusknoten sind sowohl in Rechnungs- als auch in Spesen-Workflows enthalten. Bedingungs-, Aktivitäts- und Genehmigungsknoten sind hingegen spezifisch für den jeweiligen Workflow-Typ.

Jeder Statusknoten erlaubt nur bestimmte Kombinationen von Knoten davor und danach. Die Aktion, die ausgelöst werden kann, hängt von dieser Kombination ab.

Der Workflow Designer erlaubt für Spesen-Workflows die folgenden Kombinationen:

Statusknoten

Eingehender Knoten / Eingehende Aktion

Ausgehender Knoten / Ausgehende Aktion

Entwurf

  • Start (Keine)

  • Genehmigung (Zurückrufen)

  • Bereit für Export (Transaktion) (Zurückrufen)

  • Bereit für Export (Spese) (Zurückrufen)

  • In Prüfung (Zurückrufen)

In Prüfung

Zur Korrektur

  • Aktivität (Einreichen)

  • Abgelehnt (Ablehnen)

Bereit für Spesen-Export

  • Spese exportiert
    (Export zurückziehen)

  • Spese exportiert (Export)

  • Entwurf (Zurückrufen)

  • In Prüfung (Zurück zur Prüfung)

Bereit für Transaktions-Export

  • Transaktion exportiert
    (Export zurückziehen)

  • Transaktion exportiert (Export)

  • Entwurf (Zurückrufen)

  • In Prüfung (Zurück zur Prüfung)

Spese exportiert

  • Bereit für Spesen-Export (Export)

  • Bereit für Spesen-Export (Export zurückziehen)

Transaktion exportiert

  • Bereit für Transaktions-Export (Export)

  • Bereit für Transaktions-Export (Export zurückziehen)

Abgelehnt

  • Neu (Ablehnen)

  • Entwurf (Ablehnen)

  • Zur Prüfung (Ablehnen)

  • Keine

  • Archiv (Archiv)

Archiviert

  • Abgelehnt (Archiv)

  • Keine

Spesen-Bedingungsknoten

Bedingungsknoten enthalten Bedingungen, anhand derer der nächste Schritt im Workflow ausgeführt wird. Der Workflow Designer stellt folgende Knoten zur Verfügung, um Spesenprozesse zu steuern:

Wahr-/Falsch-Bedingung (nur Professional oder Enterprise)

Konfiguriere eine Wahr/Falsch-Bedingung basierend auf bestimmten Geschäftsregeln, die Sie im JSON-Format festlegen. Beispielsweise kannst Du diese Bedingung verwenden, um zu prüfen, ob es sich bei einer Spese um einen Beleg oder eine beleglose Spese handelt, ob es sich um eine Gutschrift handelt usw.

In diesem Fall liefert die Bedingung folgende Ergebnisse:

  • True: Die im JSON angegebene Bedingung ist erfüllt (d. h. die Eigenschaft ist in der Spese vorhanden).

  • False: Die im JSON angegebene Bedingung ist nicht erfüllt (d. h. die Eigenschaft ist in der Spese nicht vorhanden).

✏️ Hinweis

Die Wahr/Falsch-Bedingung prüft auf Attribute, die auf der Spese gespeichert sind (z. B. benutzerdefinierte Felder). Wenn Du Attribute direkt auf dem Objekt prüfen müssen – etwa ob ein benutzerdefiniertes Feld in einer Tag-Dimension ausgewählt wurde – verwende die benutzerdefinierte Wahr/Falsch-Bedingung.

JSON-Regeln

Du kannst komplexe Geschäftsregeln erstellen und als JSON serialisieren.

Die JSON-Regeln werden im Feld Regeln (Rules) der Knotenoptionen angegeben.

Folgende Operationen werden unterstützt:

Zugriff auf Daten

var, missing

Logische und boolesche Operationen

if, ==, ===, !=, !== , ! , !! , or , and

Numerische Operationen

> , >= , < , <=, max, min, +, - , *, /, %

Array-Operationen

map, reduce, filter, all, none, some, merge, in

String-Operationen

in, cat, substr

Du kannst folgendes tun:

Benutzerdefiniertes Feld in der Spese prüfen

Du kannst eine Regel erstellen, um zu prüfen, ob der Wert customInformation.field vorhanden ist und ob dieser den Wert true hat. Wenn dies zutrifft, gibt die Regel den Wert true zurück.

  1. Richte das benutzerdefinierte Informationsfeld im Unternehmen ein, falls es nicht bereits von Yokoy angelegt wurde.

  2. Füge anschließend einen Wahr/Falsch-Knoten hinzu und kopiere diesen Code-Schnipsel in das Feld Regeln:

{
  "==": [
    {
      "var": [
        "customInformation.<CustomFieldLabelName>"
      ]
    },
    true
  ]
}

3. Richte den Workflow im Unternehmen ein.

✏️ Hinweis – Benutzerdefinierte Informationsfelder
Benutzerdefinierte Informationsfelder können nur von Yokoy eingerichtet werden. Möglicherweise musst Du ein Support-Ticket eröffnen,

falls das benötigte benutzerdefinierte Informationsfeld in Deiner Yokoy-Implementierung noch nicht vorhanden ist.

Prüfen, ob es sich bei der Spese um einen Beleg handelt

Du kannst eine Regel erstellen, um zu prüfen, ob es sich bei der Spese um einen Beleg handelt. Wenn dies zutrifft, gibt die Regel den Wert true zurück.

Füge einen Wahr/Falsch-Knoten hinzu und kopiere diesen Code-Schnipsel in das Feld Regeln:

{
   "in":[
      {
         "var":"expenseType"
      },
      [
         "receiptless"
      ]
   ]
}


Prüfen, ob es sich bei der Spese um eine beleglose Spese handelt

Du kannst eine Regel erstellen, um zu prüfen, ob es sich bei der Spese um eine beleglose Ausgabe handelt. Wenn das zutrifft, gibt die Regel den Wert true zurück.

Fügen Sie einen Wahr/Falsch-Knoten hinzu und kopiere diesen Code-Schnipsel in das Feld Regeln:

{
   "in":[
      {
         "var":"expenseType"
      },
      [
         "receiptless"
      ]
   ]
}


Prüfen, ob die Spese einer Reise zugeordnet ist.

Du kannst eine Regel erstellen, um zu prüfen, ob die Spese keine Benachrichtigungen oder Warnungen enthält. Wenn keine Benachrichtigungen vorhanden sind, gibt die Regel den Wert true zurück. Füge einen Wahr/Falsch-Knoten hinzu und kopiere diesen Code-Schnipsel in das Feld Regeln:

{
  "!=": [
    {
      "var": "tripId"
    },
    null
  ]
}

Prüfen, ob die Spese keine Warnungen enthält

Du kannst eine Regel erstellen, um zu prüfen, ob die Spese keine Benachrichtigungen oder Warnungen enthält. Wenn keine Benachrichtigungen vorhanden sind, gibt die Regel den Wert true zurück.

Füge einen Wahr/Falsch-Knoten hinzu und kopiere diesen Code-Schnipsel in das Feld Regeln:

{
  "==": [
    {
      "var": [
        "notifications.0"
      ]
    },
    null
  ]
}

Prüfen, ob die Spese von TravelPerk stammt

Du kannst eine Regel erstellen, um zu prüfen, ob TravelPerk als Anbieter der Spese hinterlegt ist. Wenn dies zutrifft, gibt die Regel den Wert true zurück.

{
   "==":[
      {
         "var":[
            "travelProvider"
         ]
      },
      "travelPerk"
   ]
}

💡 Tipp

Ein häufiger Anwendungsfall für diesen Knoten ist, eine doppelte Genehmigung in TravelPerk und Yokoy zu vermeiden, indem ein individueller Workflow genutzt wird.


Alternativ kannst Du – falls in Yokoy nur TravelPerk als Reiseanbieter aktiviert ist – die Genehmigungsstrategie ebenfalls verwenden, um einen zweiten Genehmigungsschritt in Yokoy zu überspringen. Du kannst Yokoy also so einstellen, dass für die Zahlungsmethode „Reiseanbieter“ keine Genehmigung erforderlich ist.

Prüfen, ob bei der Spese eine von zwei Kategorien ausgewählt ist

Du kannst eine Regel erstellen, um zu prüfen, ob bei der Spese entweder die eine oder die andere Kategorie ausgewählt wurde. Yokoy prüft dabei sowohl Spesen mit einer einzelnen Kategorie als auch solche mit mehreren Kategorien, indem die Variable splitcategories.0.categoryId verwendet wird.

✏️ Hinweis
Du musst die Kategorie-Yokoy-IDs durch die gewünschten Werte ersetzen. Andernfalls funktioniert dieses Beispiel nicht.

{
   "or":[
      {
         "in":[
            {
               "var":"categoryId"
            },
            [
               "GxjPfl9gGX",
               "4QYutTYGSg"
            ]
         ]
      },
      {
         "in":[
            {
               "var":"splitCategories.0.categoryId"
            },
            [
               "GxjPfl9gGX",
               "4QYutTYGSg"
            ]
         ]
      }
   ]
}

Benutzerdefinierte Wahr/Falsch-Bedingung (nur Professional- oder Enterprise)

Konfiguriere eine Wahr/Falsch-Bedingung basierend auf spezifischen Geschäftsregeln, die Du im JSON-Format definierst. Beispielsweise kannst Du mit dieser Bedingung prüfen, ob ein benutzerdefiniertes Kontrollkästchen für eine Tag-Dimension ausgewählt wurde.

In diesem Fall gibt die Bedingung Folgendes zurück:

  • True:

    • Die im JSON definierte Bedingung ist erfüllt.

  • False:

    • Die im JSON definierte Bedingung ist nicht erfüllt.

✏️ Hinweis
Auch wenn die benutzerdefinierte Wahr/Falsch-Bedingung der normalen Wahr/Falsch-Bedingung ähnlich erscheint, kann sie tiefer in Objekte „eintauchen“, die auf der Spese vorhanden sind.

Die Wahr/Falsch-Bedingung prüft Daten, die direkt auf der Spese angegeben sind (z. B. ein benutzerdefiniertes Feld oder ein bestimmter Wert).

Die benutzerdefinierte Wahr/Falsch-Bedingung hingegen kann auch auf andere Daten zugreifen. Beispielsweise kann sie das Kostenobjekt, dem die Spese zugewiesen ist, prüfen und entsprechende Logik anwenden.

Du kannst komplexe Geschäftsregeln erstellen und im JSON-Format serialisieren.
Die JSON-Regeln gibst Du im Feld Regeln der Knotenoptionen an. Dabei kannst Du ein sogenanntes „Drilldown“ auf mehrere Objekte durchführen:

  • Tag-Dimensionen

  • Kostenobjekte

  • Rechtliche Einheit

  • Kategorien

  • Benutzer

Beispiele:

Prüfen, ob ein benutzerdefiniertes Feld beim Tag-Wert gesetzt ist

Du kannst eine Regel erstellen, um zu prüfen, ob auf der Tag-Dimension mit einer bestimmten Yokoy-ID das benutzerdefinierte Kontrollkästchen auf true gesetzt ist (d. h. ausgewählt wurde). Wenn dies zutrifft, gibt die Regel den Wert true zurück.

  1. Identifiziere das benutzerdefinierte Feld im Unternehmen auf dem Tag (es muss ggf. von Yokoy eingerichtet werden). Der Label-Feldwert (CustomFieldLabel) muss in folgendem Ausdruck angegeben werden.

  2. Füge einen Wahr/Falsch-Knoten hinzu und kopiere diesen Code-Schnipsel in das Feld Regeln:

{
  "==": [
    {
      "var": "_tags.YOKOYID.customInformation.<CustomFieldLabel>"
    },
    true
  ]
}

3. Richte den Workflow im Unternehmen ein.

Prüfen, ob der Submitter auch der Genehmiger des Tags ist

Du kannst eine Regel erstellen, um zu prüfen, ob bei einer Tag-Dimension mit einer bestimmten Yokoy-ID die Genehmigenden im Tag-Array dem Submitter entsprechen. Füge einen Wahr/Falsch-Knoten hinzu und kopiere diesen Code-Schnipsel in das Feld Regeln:

{
   "in":[
      {
         "var":"userId"
      },
      {
         "var":"_tags.<YokoyTagDimensionID>.approverIds"
      }
   ]
}

🚧 Vorsicht
Stelle sicher, dass Du <YokoyTagDimensionID> durch Deine Tag-Dimension-ID ersetzt.

Prüfen, ob ein benutzerdefiniertes Feld in der Kategorie der Spese gesetzt ist

Du kannst eine Regel erstellen, um zu prüfen, ob in der bei der Spese eingereichten Kategorie das benutzerdefinierte Kontrollkästchen auf true gesetzt ist (d. h. ausgewählt wurde). Wenn dies zutrifft, gibt die Regel den Wert true zurück.

  1. Identifiziere das benutzerdefinierte Feld in der Kategorie (es muss ggf. von Yokoy eingerichtet werden).

  2. Der Label-Feldwert (CustomFieldLabel) muss im folgenden Ausdruck angegeben werden.

Füge einen Wahr/Falsch-Knoten hinzu und kopiere diesen Code-Schnipsel in das Feld Regeln:

{
  "some": [
    {
      "var": "_categories"
    },
    {
      "==": [
        {
          "var": "customInformation.<CustomFieldLabel>"
        },
        true
      ]
    }
  ]
}

Betragsprüfung (Spese) (nur Professional oder Enterprise)

Konfiguriere eine Wahr/Falsch-Bedingung (Guard), um zu prüfen, ob eine Spese eine bestimmte Betragsbedingung erfüllt.

Beispielsweise kannst Du die Logik so einrichten, dass Yokoy bei Spesen zwischen 10 und 100 CHF den Genehmigungsprozess überspringt und direkt zu In Prüfung weiterleitet. Andernfalls wird ein Tag-Genehmigungsprozess gestartet.

In diesem Fall liefert die Bedingung folgende Ergebnisse:

  • Wahr:

    • Die Betragsbedingung ist erfüllt.

  • Falsch:

    • Die Betragsbedingung ist nicht erfüllt.

Diese spezielle Bedingung bietet verschiedene Optionen:

Option

Akzeptierter Wert

Beschreibung

Aggregations-typ

Single oder Day

  • Einzeln: Vergleich auf Basis jeder einzelnen Spese mit dem Schwellenwert

  • Tag: Aggregiert alle Spesen desselben Kalendertags

Operator

>, >=, <, <=

  1. Größer als (>)

  2. Größer oder gleich (>=)

  3. Kleiner als (<)

  4. Kleiner oder gleich (<=)

Währung

String
​

Die zu berücksichtigende Währung. Verwende den 3-stelligen ISO-4217-Code (z. B. CHF, EUR, USD).

Schwellenwert

Nummer

Der Betrag für die Prüfung.
Beispiel: Wenn Du 100 angibst, werden alle Spesen, die – abhängig vom gewählten Operator – größer, kleiner oder gleich diesem Betrag sind, entsprechend ausgewertet.

Nach Anzahl Teilnehmender normalisieren

true / false

Wenn Du dieses Kontrollkästchen aktivierst, prüft Yokoy die Anzahl der Teilnehmenden und teilt den Spesenbetrag durch die Anzahl der Nutzer, die sich die Spese teilen.

Du kannst die Logik so einrichten, dass Yokoy prüft, ob eine Spese mehr als 150 CHF beträgt (ohne Berücksichtigung der Anzahl an Teilnehmenden). Wenn der Betrag über 150 CHF liegt, gibt die Bedingung den Wert true zurück.

Der Aggregationstyp bestimmt dabei, ob jede Spese einzeln geprüft wird oder ob die Beträge eines Tages kumuliert betrachtet werden. Diese Einstellung ist besonders relevant in Szenarien mit täglichen Pauschalen. Hat ein Mitarbeitender zum Beispiel eine Tagespauschale von 40 CHF für das Mittagessen, führt der Aggregationstyp Single dazu, dass zwei eingereichte Mittagessen à 30 CHF jeweils separat geprüft werden – beide würden dabei den Wert true zurückgeben. Wird jedoch der Aggregationstyp Day verwendet, werden die Spesen desselben Kalendertages summiert. In diesem Fall würde die erste Spese von 30 CHF noch als zulässig gelten (true), die zweite jedoch – da der Tagesgesamtbetrag nun 60 CHF beträgt – den Wert false zurückgeben.

Betragsvalidierung (Kategorie) (nur Enterprise)

Konfiguriere eine Wahr/Falsch-Bedingung, wenn die Logik zutrifft. Im Gegensatz zur Betragsvalidierung (Spese) prüft diese Bedingung den Betrag pro Spesenkategorie. Der Schwellenwert wird direkt in der Kategorie als benutzerdefiniertes Feld definiert – nicht im Bedingungsknoten selbst.

Beispiel: Du richtest eine Logik ein, die Yokoy anweist, den Genehmigungsfluss zu überspringen und direkt in den Status In Prüfung zu wechseln, wenn die Summe der Spesen für eine Kategorie zwischen 100 und 500 CHF liegt. Andernfalls soll ein Tag-Genehmigungsprozess ausgelöst werden.

In diesem Fall ergibt die Bedingung:

  • True:
    Die Betragsbedingung ist erfüllt.

  • False:
    Die Betragsbedingung ist nicht erfüllt.

Diese spezielle Bedingung bietet verschiedene Optionen:

Option

Akzeptierter Wert

Beschreibung

Aggregations-typ

Single oder Day

  • Einzeln: Vergleich mit dem Schwellenwert auf Basis jeder einzelnen Spese

    Tag: Aggregiert alle Spesen nach Kategorie innerhalb desselben Kalendertages

Operator

>, >=, <, <=

  • Größer als (>)

  • Größer oder gleich (≥)

  • Kleiner als (<)

  • Kleiner oder gleich (≤)

Aggregations-Logik

any, all

  • Alle:
    Yokoy prüft alle Kategorien der Spese. Nur wenn alle Kategorien die Bedingung erfüllen, wird „Wahr“ zurückgegeben.

  • Beliebig:
    Yokoy prüft alle Kategorien der Spese. Wenn mindestens eine Kategorie die definierte Bedingung erfüllt, wird „Wahr“ zurückgegeben.

    Kategorien ohne definierten Schwellenwert werden ignoriert.

Normalisieren nach Anzahl der Teilnehmenden

true / false

Wenn Du dieses Kontrollkästchen aktivierst, prüft Yokoy die Anzahl der Teilnehmenden und teilt den Spesenbetrag durch die Anzahl der User, die sich die Spese teilen.

Benutzerdefinierte Felder für die Betragsvalidierung nach Kategorie einrichten

Um diese Bedingung nutzen zu können, benötigst Du zwei benutzerdefinierte Felder (Additional fields) für Spesenkategorien (siehe Bild):

  • customInformation.thresholdCurrency: Die Währung des Schwellenwerts (z. B. CHF, EUR usw.)

  • customInformation.thresholdAmount: Der Betrag des Schwellenwerts (z. B. 50, 100 usw.)

Diese benutzerdefinierten Felder müssen möglicherweise zuerst von Yokoy eingerichtet werden. Gib bei der Einrichtung der benutzerdefinierten Felder im Bereich Admin > Firmeneinstellungen > Admin Support Section die folgenden Namen ein: thresholdCurrency und thresholdAmount. Diese Felder müssen für die Kategorien definiert werden.

Name

Bezeichnung

Typ

thresholdAmount

Schwellenwert-Betrag

Text input (Texteingabe)

thresholdCurrency

Schwellenwert-Währung

Text input (Texteingabe)

Dieser Schritt muss für jede Gesellschaft durchgeführt werden, in der Du den Workflow mit dem Knoten Betragsvalidierung nach Spesenkategorie verwenden möchtest.

Der Schwellenwert wird direkt in der Kategorie-Konfiguration festgelegt.
Er gilt für Spesen, die dieser Kategorie zugeordnet sind, und hängt vom Aggregationstyp (Einzeln/Tag), dem Operator und der im Workflow definierten Logik ab.

Betragsvalidierung (Reise) (nur Professional oder Enterprise)

Konfiguriere eine Wahr/Falsch-Bedingung für Spesen mit Reisen, um zu prüfen,

ob der Gesamtbetrag der Reise den definierten Schwellenwert (in der Währung der Gesellschaft) überschreitet.

Beispiel:
Richte eine Logik ein, die Yokoy anweist zu prüfen, ob der Reisebetrag höher ist als der definierte Schwellenwert.

In diesem Fall ergibt die Bedingung:

  • True:
    Die Betragsbedingung ist erfüllt. Der Gesamtbetrag der Reise ist größer als der Schwellenwert.

  • False:
    Die Betragsbedingung ist nicht erfüllt. Der Gesamtbetrag der Reise ist kleiner als der Schwellenwert.

Diese spezielle Bedingung hat eine Option:

Option

Akzeptierte Werte

Beschreibung

Threshold amount (Schwellenwert-Betrag)

Nummer

Der Schwellenwert für die Validierung. Dieser Betrag wird mit dem Gesamtbetrag der Reise verglichen – zum Beispiel 100. Die Währung wird dabei aus der Gesellschaft übernommen.

Steuersätze unvollständig (nur Enterprise)

Konfiguriere eine Wahr/Falsch-Bedingung, um zu prüfen, ob einem Dokument ein Steuerschlüssel zugewiesen wurde und ob die aus der Ausgabe extrahierten Steuerbeträge korrekt sind.

  • Wahr:
    Wenn der Steuerschlüssel unvollständig ist oder die Summe der Steuerbeträge nicht korrekt ist, gibt die Bedingung „wahr“ zurück.

  • Falsch:
    Wenn der Steuerschlüssel vollständig ist und die Summe der Steuerbeträge korrekt ist, gibt die Bedingung „falsch“ zurück.

Beispiel:
Wenn eine Spese Steuern enthält (mit oder ohne aufgeteilte Kategorien), der Steuerschlüssel jedoch fehlt oder die Bruttobeträge der Steuer nicht mit dem Gesamtbetrag der Spese übereinstimmen, wird „wahr“ zurückgegeben.

Dieser Knoten enthält zwei Optionen:

Option

Akzeptierte Werte

Beschreibung

Exclude zero tax rates

true / false

Wenn ausgewählt, betrachtet Yokoy Null-Prozent-Steuersätze nicht als gültige Steuersätze.

Return false for allowances

true / false

Wenn ausgewählt, ignoriert Yokoy.

Standardmäßig betrachtet Yokoy Nullsteuersätze als gültige Steuerschlüssel.
Das bedeutet: Wenn eine Spese mit einem Nullsteuersatz eingereicht wird, gibt die Bedingung „falsch“ zurück. Du kannst dieses Verhalten jedoch überschreiben,

indem Sie das Kontrollkästchen „Nullsteuersätze ausschließen“ aktivierst.
Dann gilt: Wenn eine Spese einen Nullsteuersatz hat, gibt die Bedingung „wahr“ zurück. Zusätzlich kannst Du Tagespauschalen von dieser Steuerprüfung ausschließen, da solche in der Regel keine Steuer enthalten.

Einreichung bei eigener Kostenstelle (nur Professional oder Enterprise)

Richte eine Bedingung ein, die wahr oder falsch zurückgibt, je nachdem, ob das Kostenobjekt der Spese mit dem Kostenobjekt des Submitters übereinstimmt.

  • True:
    Der Eigentümer des Kostenobjekts, das der Spese zugewiesen ist, ist dieselbe Person, welche die Spese eingereicht hat.

  • False:
    Der Eigentümer des Kostenobjekts ist nicht dieselbe Person wie die einreichende Person.

Beispiel:
Alex Smith reicht eine Spese ein, die dem Kostenobjekt „Produktion“ zugewiesen ist. Alex ist auch der Eigentümer des Kostenobjekts „Produktion“ – Yokoy gibt „wahr“ zurück. Wenn jedoch ein anderer User – z. B. Jan – eine Spese auf dasselbe Kostenobjekt einreicht, gibt Yokoy „falsch“ zurück.

Submitter mit Eigenschaft (nur Professional oder Enterprise)

Konfiguriere einen Bedingungsknoten, der true oder false zurückgibt, je nachdem, ob der Submitter eine bestimmte Eigenschaft besitzt. Du kannst beliebige Benutzereigenschaften prüfen, z. B. Name, E-Mail, Vorgesetzte(r) oder benutzerdefinierte Felder.

In diesem Fall ergibt die Bedingung:

  • True:
    Das Kostenobjekt, das mit der Ausgabe des Einreichenden verknüpft ist, enthält den definierten Eigenschaftswert.

  • False:
    Das Kostenobjekt enthält nicht den definierten Eigenschaftswert.

Beispiel:
Die Bedingung ist auf die Eigenschaft Line manager Vorgesetzter mit dem Wert Alex Smith konfiguriert.

  • Wenn ein User eine Spese einreicht und dessen Vorgesetzte(r) Alex Smith ist, gibt Yokoy „wahr“zurück.

  • Wenn dagegen der/die Vorgesetzte Devis Hirt ist, gibt Yokoy falsch zurück.

Option

Akzeptierte Werte

Beschreibung

Eigenschaft

String

Name (ID) des Feldes, das auf der Kostenstelle geprüft werden soll.
Zum Beispiel kann dies jedes beliebige Feld sein, das im Kostenobjekt vorhanden ist – vom Namen der Kostenstelle bis hin zu einem benutzerdefinierten Feld.

Matches

String / Nummer / Boolescher Wert

Wert der Kostenstellen-Eigenschaft, der überprüft werden soll.

Um mehrere Werte hinzuzufügen, klicke auf + Zeile hinzufügen.

Einrichtung der Submitter-Eigenschaftsprüfung für ein benutzerdefiniertes Feld

Wenn Du z. B. prüfen möchtest, ob das benutzerdefinierte Feld Target Administration beim User den Wert "G000" oder "G001" enthält:

  1. Identifiziere das benutzerdefinierte Feld, das beim Benutzer erstellt wurde.

    Falls dieses noch nicht eingerichtet ist, müssen Sie möglicherweise Yokoy darum bitten. Merke Dir den Name-Wert, da Du ihn im nächsten Schritt benötigst.

    • Name: customInformation.targetAdministration

    • Label: Target Administration

    • Typ: Texteingabe

2. Klicke im Workflow-Designer auf den Knoten Submitter mit Eigenschaft und gib folgende Daten ein. Da Du mehrere Werte prüfen möchtest, gib den Wert „G001“ ein und klicke anschließend auf + Zeile hinzufügen, um den zweiten Wert „G002“ hinzuzufügen:

  • Property (Eigenschaft): customInformation.targetAdministration

  • Matches: G001

  • Matches: G002

In diesem Fall prüft Yokoy, ob der Submitter diese Eigenschaft besitzt. Wenn ja,

wird eine Genehmigung für das Kostenobjekt durchgeführt. Wenn nein, wird das Dokument in den Status In Prüfung verschoben.

Kostenstelle mit Eigenschaft (nur Professional oder Enterprise)

Konfiguriere einen Bedingungsknoten, der wahr oder falsch zurückgibt, je nachdem, ob das Kostenobjekt eine bestimmte Eigenschaft enthält. Du kannst jede Eigenschaft eines Kostenobjekts prüfen – z. B. Kostenstellen-Name, ERP-Code, benutzerdefinierte Felder usw.

In diesem Fall ergibt die Bedingung:

  • True: Das Kostenobjekt, das mit der Spese des Submitters verknüpft ist,

    besitzt den definierten Eigenschaftswert.

  • False: Das Kostenobjekt besitzt nicht den definierten Eigenschaftswert.

Beispiel: Die Bedingung ist auf die Eigenschaft Name gesetzt und prüft auf den Wert Sales.

  • Wenn eine Spese einer Kostenstelle mit dem Namen „Sales“ zugewiesen wird, gibt Yokoy wahr zurück.

  • Wird die Ausgabe hingegen dem Kostenobjekt „Manufacturing“ zugewiesen, gibt Yokoy falsch zurück.

Option

Akzeptierte Werte

Beschreibung

Property (Eigenschaft)

String

Name (ID) des Feldes, das bei der Kostenstelle geprüft werden soll.

Zum Beispiel kann das jedes Feld sein, das im Kostenobjekt vorhanden ist – vom Namen der Kostenstelle bis hin zu einem benutzerdefinierten Feld.

Matches one of

String / Nummer / Boolescher Wert

Wert der Kostenstellen-Eigenschaft,

die geprüft werden soll.

Um mehrere Werte hinzuzufügen,

klicke auf + Zeile hinzufügen.

Requires independence

(benötigt Unabhängigkeit)

true / false

Wenn Du dieses Kontrollkästchen aktivierst, darf der Genehmigende des Kostenobjekts nicht identisch mit dem Submitters sein. Ist der Genehmigende des Kostenobjekts dieselbe Person wie der Submitter, gibt die Bedingung false zurück.

Require approvers

(Benötigt Genehmiger:in)

true / false

Wenn Du dieses Kontrollkästchen aktivierst, muss das Kostenobjekt eine(n) Genehmiger:in haben.
Falls das Kostenobjekt – auch wenn es eine Übereinstimmung gibt – keine:n Genehmiger(in) hat, gibt die Bedingung false zurück.

Einrichtung der Kostenobjekt-Eigenschaftsprüfung für ein benutzerdefiniertes Feld

Wenn Du bspw. prüfen möchtest, ob das Kostenobjekt, das bei der Spese eingereicht wurde, als Spezialkostenobjekt markiert ist (Checkbox Special cost object ist auf true gesetzt):

  1. Identifiziere das benutzerdefinierte Feld im Kostenobjekt (falls nicht verfügbar, musst Du möglicherweise Yokoy um die Einrichtung bitten). Merke Dir den Namen, da Du ihn im nächsten Schritt benötigst.

  • Name: customInformation.specialCostObject

  • Label: Special cost object

  • Typ: Checkbox

2. Klicke im Workflow-Designer auf den Knoten Kostenobjekt mit Eigenschaft und gib folgende Daten ein:

  • Property (Eigenschaft): customInformation.specialCostObject

  • Matches: true

Da Du prüfen möchtest, ob die Checkbox markiert ist, gib den Wert „true“ ein.

In diesem Fall prüft Yokoy, ob das eingereichte Kostenobjekt eine Spezialkostenstelle ist. Falls true, wird die Genehmigung für das Kostenobjekt übersprungen. Falls false, wird der Genehmigungsprozess durchgeführt.

Mit Firmenkarte bezahlt

Konfiguriere eine Wahr/Falsch-Bedingung, um zu prüfen, ob eine Spese mit einer Firmenkreditkarte bezahlt wurde.

In diesem Fall ergibt die Bedingung:

  • True: Die Spese wurde mit einer Firmenkarte bezahlt

  • False: Die Spese wurde nicht mit einer Firmenkarte bezahlt

🚧 Vorsicht
Dieser Knoten wird als Exportbedingung für Kartentransaktionen verwendet.
Er MUSS immer am Ende des Workflows platziert werden, um den Exportpfad klar zu unterscheiden. Er kann aber auch in anderen Szenarien eingesetzt werden, z. B. nach dem Einreichen, um Spesen in einen anderen Workflow zu leiten.

Spese-Aktivitätsknoten

Spese-Aktivitätsknoten führen im Workflow eine spezifische Aktion am Dokument aus. Im Workflow kannst Du folgende Aktionen durchführen:

✏️ Hinweis

Vor dem Aktivitätsknoten benötigst Du einen Statusknoten (z. B. „Entwurf“ oder „Überarbeitung erforderlich“). Nach dem Aktivitätsknoten kannst Du jeden anderen Knotentyp im Workflow hinzufügen (Status-, Aktivitäts-, Bedingungs- oder Genehmigungsknoten). Ein Aktionspfad ist nicht erforderlich.

Alle Kostenobjekt-Genehmiger zuweisen

Weise alle Eigentümer:innen der Kostenobjekte als Genehmiger:innen zu.
Technisch gesehen wird durch die verschiedenen Kostenobjekte der Spese iteriert, die jeweiligen Eigentümer:innen extrahiert und für die Genehmigung zugewiesen.

💡 Tipp
Verwende es mit der Kostenobjekt-Genehmigung um einen Kostenobjekt-Flow zu erstellen.

Beispiel: Du konfigurierst Yokoy so, dass alle Eigentümer:innen der Kostenobjekte zugewiesen werden und eine Genehmigung von allen erforderlich ist, wenn eine Spese eingereicht wird.

In diesem Fall ergibt die Bedingung:

  • True: Wenn Yokoy keine:n Genehmiger:in findet, bleibt das Dokument im aktuellen Status.

  • False: Wenn Yokoy keine:n Genehmiger:in findet, wird das Dokument in den nächsten Status verschoben.

🚧 Vorsicht
Wenn Delegierte eingetragen sind, deren Vertretungszeitraum abgelaufen ist, werden diese nicht in die Genehmigung aufgenommen. Diese Delegierten werden ignoriert, da ihr Ablaufdatum in der Vergangenheit liegt.

Benutzerdefinierte Genehmiger für Kostenobjekte zuweisen (nur Enterprise)

Ermittelt alle Eigentümer der Kostenobjekte als Genehmigende.

Technisch gesehen wird es durch die verschiedenen Kostenstellen einer Spese iteriert, und es werden Genehmigende basierend auf den in den Optionen definierten Eigenschaften zugewiesen.

💡 Tipp
Verwende diesen Knoten zusammen mit der Kostenobjekt-Genehmigung,

um einen vollständigen Kostenobjekt-Workflow abzubilden.

Dieser Knoten enthält Optionen, die ausgefüllt werden müssen:

Option

Akzeptierte Werte

Beschreibung

Kostenobjekt-Feld

String

Das Feld im Kostenobjekt, das abgefragt werden soll.

Benutzerfeld

String

Benutzereigenschaft im Kostenobjekt.

Erforderliche Genehmiger:innen

true / false

  • True: Es muss mindestens ei Genehmiger für das Kostenobjekt definiert sein.
    Wenn keine Genehmigenden vorhanden sind, wird die Spese nicht in den nächsten Schritt weitergeleitet.

  • False: Es ist kein Genehmiger erforderlich.

Transformations

lowercase

Wenn Yokoy die Groß- und Kleinschreibung im Benutzerfeld ignorieren soll, aktiviere dieses Kontrollkästchen.
Wenn aktiviert, erkennt Yokoy z. B. „USER.COMPANY@COMPANY.com“ korrekt als „user.company@company.com“.

Beispiel: Du möchtest eine spezielle Person (die nicht Eigentümer:in des Kostenobjekts ist) für die Genehmigung zuweisen, basierend auf dem im Kostenobjekt hinterlegten Wert:

  1. Prüfe , ob das benutzerdefinierte Feld approverMail im Kostenobjekt vorhanden ist (falls nicht, müssen Sie ggf. Yokoy bitten, dieses einzurichten).

  2. Verweise im Workflow auf das Kostenobjekt-Feld (in diesem Fall:
    ​customInformation.approverMail) sowie auf das entsprechende Benutzerfeld, in dem Yokoy die E-Mail-Adressefindet, um den User zu identifizieren (z. B. das Standardfeld E-Mail).

  3. In diesem Fall kannst Du beliebige User-E-Mail-Adressen im Kostenobjekt angeben, und Yokoy weist diese Person als Genehmigende zu.
    Das bedeutet: Der Submitter wählt ein Kostenobjekt in der Spese aus.
    Yokoy liest aus diesem Kostenobjekt die im E-Mail-Feld hinterlegte Adresse aus und weist den entsprechenden User zur Genehmigung zu.

✏️ Hinweis

Dieses Feld ist nicht groß-/klein­schreibungs­empfindlich. Wenn Du z. B. „USER.COMPANY@COMPANY.com“ eingibst, kann Yokoy dies mithilfe des Transformationsfelds in „user.company@company.com“ umwandeln.

Alle Tag-Genehmiger/innen zuweisen (nur Professional oder Enterprise)

Weist alle Tag-Genehmiger:innen mit einem bestimmten Tag-Wert zu, der auf dem Rechnungsdokument gefunden wird. Technisch gesehen wird jede Rechnungszeile durchlaufen, die Tag-Werte werden extrahiert und entsprechende Genehmiger:innen zur Freigabe zugewiesen.

💡 Tipp
Verwende es mit der endgültigen Genehmigung, um einen Tag-basierten Freigabeprozess zu erstellen.

Der Knoten verfügt über zwei Optionen:

Option

Akzeptierte Werte

Beschreibung

Genehmiger:in erforderlich

true / false

  • True: Es muss mindestens ein Genehmiger für das Tag definiert sein. Wenn kein Genehmiger vorhanden ist, wird der Workflow gestoppt.

  • False: Für das Tag ist kein Genehmiger erforderlich.
    In diesem Fall wird der Workflow normal im nächsten Schritt fortgesetzt.

Tag-Dimension-ID

String

Zu verwendende Tag-Dimension

Du kannst eine oder mehrere Tag-Dimensionen angeben, die von Yokoy berücksichtigt werden sollen.
Es ist möglich, beliebig viele Dimensionen hinzuzufügen.

Beispiel: Du kannst bei einer Spese zwei Tag-Dimensionen einrichten –
eine für die Genehmigung und eine für die Kontierung. Yokoy kann so konfiguriert werden, dass nur die gewünschte Dimension berücksichtigt wird. Wenn Du das Feld Tag-Dimension-ID leer lassen, berücksichtigt Yokoy standardmäßig alle im Dokument vorhandenen Tag-Dimensionen.

🚧 Vorsicht
Tag-Dimension-IDs sind spezifisch für jede Umgebung und Organisation.

Beim Konfigurieren von Tag-Workflows gibt es zwei Möglichkeiten im Umgang mit IDs:

  • Keine Tag-Dimension-ID im Workflow angeben: Der Workflow berücksichtigt alle Tag-Dimensionen auf dem Rechnungsdokument. Das bedeutet, dass der Workflow umgebungsübergreifend wiederverwendet werden kann – ohne Änderungen.

  • Tag-Dimension-IDs im Workflow angeben: Der Workflow berücksichtigt nur die angegebene Tag-Dimension. Das bedeutet, dass Sie einen separaten Workflow erstellen müssen – einen mit der TEST-Tag-Dimension-ID und einen weiteren mit der PROD-Tag-Dimension-ID.

Beispiel: Du konfigurierst Yokoy so, dass beim Einreichen alle Tag-Genehmigenden zugewiesen werden. Jeder dieser Genehmigenden kann genehmigen, um den Workflow abzuschließen.

Vorgesetzten zuweisen

Richte einen Schritt ein, um alle Vorgesetzten der Person, welche die Spese eingereicht hat, als Genehmigende zuzuweisen.

🚧 Vorsicht
Dieser Knoten muss zusammen mit Genehmigung durch Vorgesetzten oder Eskalation verwendet werden.

Der Knoten kommt mit folgenden Optionen:

Option

Akzeptierte Werte

Beschreibung

Delegierten-unabhängigkeit verwerfen

true / false

Standardmäßig wird der Delegierte nur dann hinzugefügt, wenn er nicht identisch mit dem Submitter oder dem User der Spese ist. Du kannst dieses Kontrollkästchen aktivieren, um anzugeben, dass der Delegierte auch dann hinzugefügt werden soll wenn er identisch mit dem Submitter bzw. dem User der Spese ist.

Statischen Genehmiger zuweisen (nur Enterprise)

Richtet eine(n) Genehmiger:in anhand einer spezifischen ID ein. Kurz gesagt: Es wird ein bestimmter User zur Genehmigung für die Gesellschaft zugewiesen.

Das wird häufig verwendet, um eine finale Genehmigungsperson festzulegen – z. B. bei Ausgaben über 50.000 €, Genehmigung durch den CEO.

Dieser Knoten verfügt über eine Option:

Option

Akzeptierte Werte

Beschreibung

Approver ID

String

User-ID des zur Genehmigung verwendeten Users.

Du kannst mehrere User hinzufügen, indem Du auf + Zeile hinzufügen klickst.

Zum Beispiel kannst Du eine Aktivität einrichten, damit Yokoy einen bestimmten User als Genehmiger:in zuweist.

Genehmiger mit Eigenschaft zuweisen (nur Professional oder Enterprise)

Bestimmt Genehmiger:innen basierend auf einer bestimmten User-Eigenschaft.

Das kann verwendet werden, um Genehmigungsgruppen zu erstellen oder User dynamisch zuzuweisen, basierend auf spezifischen benutzerdefinierten Eigenschaften, die im Benutzerprofil hinterlegt sind. In diesem Fall liefert die Bedingung folgende Ergebnisse:

  • True: Es wird ein(e) Genehmiger:in gemäß den in der Aktion angegebenen Optionen benötigt. Ist kein(e) entsprechende(r) Genehmiger:in vorhanden,

    wird nicht fortgefahren.

  • False: Es wird ebenfalls ein(e) Genehmiger:in gemäß den in der Aktion angegebenen Optionen benötigt. Ist kein(e) entsprechende(r) Genehmiger:in vorhanden, wird fortgefahren.

Diese spezielle Bedingung verfügt über auszufüllende Optionen:

Option

Akzeptierte Werte

Beschreibung

Eigenschaft

String

Datenfeld der Benutzereigenschaft

Zum Beispiel:

  • Vorname des Users: user.FirstName

  • Nachname des Users: user.LastName

  • E-Mail-Adresse des Users: user.email

  • ERP-Code des Users: user.employeeId

  • Benutzerdefiniertes Feld: customInformation.<customFieldName>

Wert

String / Nummer / Boolescher Wert

Wert des Attributs in Yokoy

Zum Beispiel:

  • user.name: Alex

  • user.lastName: Smith

  • user.email: alex.smith@example.com

  • user.employeeId: 1234

  • customInformation.[labelName]:

    • Bei einem Texteingabefeld: ein String wie z. B. „manufacturing“ oder „G004“

    • Bei einem Kontrollkästchen: true / false

Antragsteller ignorieren

true / false

Beim Abrufen des Eigenschaftsfelds,

wenn eine Liste von Usern gefunden wird, lässt Yokoy den „Claimant“ (also den User, dem die Spese gehört) außen vor. Dies ist nicht zwangsläufig der User, der die Spese einreicht, da sie auch von einem Assistenten oder Finanz-User erstellt worden sein könnte.

Frühere Genehmiger:innen ignorieren

true / false

Beim Abrufen des Eigenschaftsfelds, wenn eine Liste von Usern gefunden wird, überspringt Yokoy auch alle Benutzer, die bereits genehmigt haben.

🚧 Groß-/Kleinschreibung bei Eigenschaften beachten

Der Workflow Designer berücksichtigt die Groß- und Kleinschreibung.
Stelle daher sicher, dass Du true oder false in Kleinbuchstaben schreibst. Andernfalls erkennt der Workflow Designer den Booleschen Wert nicht.

❗️Warnung

Stelle sicher, dass mindestens ein User das Kontrollkästchen aktiviert hat – ansonsten kann Yokoy keinen Genehmiger zuweisen und der Workflow schlägt fehl.

Die Kontrollkästchen Antragsteller ignorieren und Ignoriere frühere Genehmiger/innen ermöglichen es, das Verhalten einzuschränken, wenn für eine Eigenschaft eine Liste von Usern gefunden wird.

Beispiel: Eine Spese wird zunächst über das Kostenobjekt genehmigt.
Anschließend erfolgt eine zusätzliche Genehmigung durch das Executive Team (konfiguriert über eine Kennzeichnung im Benutzerprofil). Wenn der CFO bereits genehmigt hat (z. B. als Teil der Kostenobjekt-Genehmigung in der ersten Stufe), muss er in der zweiten Stufe nicht erneut genehmigen, sofern das Kontrollkästchen Ignoriere frühere Genehmiger/innen aktiviert ist. Andernfalls müsste der CFO dieselbe Spese zweimal genehmigen. Diese Option dient der Umsetzung des Vier-Augen-Prinzips: Wenn zwei unabhängige Genehmiger:innen erforderlich sind, stellt diese Option sicher, dass nicht dieselbe Person zweimal genehmigt.

Beispiel:
Du kannst Yokoy so einrichten, dass alle User, bei denen die Eigenschaft customInformation.TeamA auf true gesetzt ist, zur Genehmigung zugewiesen werden.
Das bedeutet, alle User, die in ihrem Profil das Kontrollkästchen „Team A“ aktiviert haben, automatisch zur Genehmigung herangezogen werden.

Alle Kostenobjektgenehmiger zuweisen (nur Enterprise)

Weist die Vorgesetzten aller Eigentümer von Kostenstellen als Genehmiger zu.
Yokoy prüft den Wert der Kostenstelle und weist den Vorgesetzten des jeweiligen Kostenstellen-Eigentümers zu, der die Bedingungen erfüllt.
Wenn keine dynamische Eskalation konfiguriert ist, wird generell der Vorgesetzte des Kostenstellen-Eigentümerszugewiesen – ohne weitere Prüfung.

Beispiel:
Du konfigurierst Yokoy so, dass die Vorgesetzten aller Kostenstellen-Eigentümer zur Genehmigung zugewiesen werden und alle Eigentümer genehmigen müssen, wenn eine Rechnung eingereicht wird.

💡 Tipp
In Kombination mit einem Genehmigungsknoten wie Endgültige Genehmigung verwenden.

In diesem Fall liefert die Bedingung folgende Ergebnisse:

  • True: Wenn Yokoy keinen Genehmiger findet, bleibt das Dokument im aktuellen Status.

  • False: Wenn Yokoy keinen Genehmiger findet, wird das Dokument in den nächsten Status überführt.

Genehmigungsknoten für Spesen

Genehmigungsknoten für Spesen ergänzen Aktivitätsknoten im Workflow,

um spezifische Geschäftslogik umzusetzen. Der Workflow Designer enthält folgende Genehmigungsknoten:

✏️ Hinweis
Vor einem Genehmigungsknoten ist ein Aktivitätsknoten erforderlich.
Nach einem Genehmigungsknoten müssen Statusknoten wie Zur Korrektur, Entwurf, Abgelehnt oder In Prüfung folgen.

Endgültige Genehmigung (nur Professional oder Enterprise)

Verwende diesen Knoten, um je nach Bedarf verschiedene Arten von Genehmigungsprozessen einzurichten. Technisch gesehen bewirkt dieser Knoten Folgendes: Wenn einem Dokument eine oder mehrere genehmigende Personen zugewiesen werden und eine dieser Personen das Dokument genehmigt, wird die Liste der Genehmiger:innen vom Dokument entfernt und der nächste Schritt im Ablauf wird ausgeführt. Mit anderen Worten: Jede genehmigende Person kann den Genehmigungsprozess beenden und das Dokument zum nächsten Schritt im Workflow weiterleiten.

💡 Tipp

Verwende diesen Knoten zusammen mit folgenden Aktivitätsknoten:

Kostenobjekt-Genehmigung

Genehmigungsfluss für ein Kostenobjekt konfigurieren. Technisch gesehen übernimmt dieser Knoten die vom Aktivitätsknoten ermittelte(n) Genehmiger:innen-Liste und sendet das Dokument zur Genehmigung an diese Person(en).

Der Genehmigungsprozess läuft so lange, bis alle Personen auf der Liste ihre Zustimmung erteilt haben. Er wird in Kombination mit den Aktivitätsknoten Alle Kostenobjektgenehmiger zuweisen oder Weise benutzerdefinierte Kostenobjekt-Gehnemiger zu verwendet.

Dieser Knoten kann eine Eskalation auf das übergeordnete Kostenobjekt durchführen. Das geschieht in den Standard-Workflows von Yokoy in folgenden Fällen:

  • Wenn der Submitter selbst Eigentümer des Kostenobjekts ist, wird die Spese zur Genehmigung an den Eigentümer des übergeordneten Kostenobjekts weitergeleitet.

  • Wenn das Auto-Genehmigungslimit (Approval Threshold) des Kostenobjekts überschritten wird, erfolgt ebenfalls eine Weiterleitung an den Eigentümer des übergeordneten Kostenobjekts.

Option

Akzeptierte Werte

Beschreibung

Überprüfe die Unabhängigkeit

Boolescher Wert (true/false)

Wird an das übergeordnete Kostenobjekt eskaliert, wenn der Submitter mit der genehmigenden Person übereinstimmt. Das bedeutet, dass wenn eine Person ein Dokument genehmigt, prüft Yokoy, ob diese Person auch die Einreichung vorgenommen hat. Falls ja, wird die Genehmigung an das übergeordnete Kostenobjekt eskaliert.

An übergeordnetes Kostenobjekt eskalieren

Boolescher Wert (true/false)

Yokoy prüft außerdem das Genehmigungslimit des Kostenobjekts. Wenn dieses Limit überschritten wird, wird das Dokument ebenfalls an das übergeordnete Kostenobjekt eskaliert.

Wenn die Spese mithilfe dieses Knotens automatisch eskaliert wird, wird diese Information in der Spesenhistorie wie gefolgt protokolliert:

Genehmigung weitergeleitet – Zusätzliche unabhängige Genehmigung vom Kostenobjekt (Person) notwendig.

Genehmigung weitergeleitet – Zusätzliche Genehmigung von Kostenobjekt (Person) notwendig (Grund: Schwellenwert von Kostenobjekt (Name) überschritten).

Genehmigung durch Vorgesetzten oder Eskalation

Konfiguriere einen speziellen Genehmigungsprozess in Kombination mit Vorgesetzten zuweisen.

🚧 Vorsicht
Dieser Knoten muss vor dem Knoten „Vorgesetzten zuweisen“ verwendet werden – andernfalls funktioniert er nicht.

Dieser spezielle Knoten verfügt über eine Option, die zwingend konfiguriert werden muss:

Option

Akzeptierte Werte

Beschreibung

Betragsreferenz

expense / trip

  • Spesen: Yokoy vergleicht den Spesenbetrag mit dem Genehmigungslimit des Vorgsetzten des Users, um zu bestimmen, ob eine Eskalation erforderlich ist.

  • Reise: Yokoy vergleicht den gesamten Reisebetrag mit dem Genehmigungslimit des Vorgsetzten des Users, um zu bestimmen, ob eine Eskalation erforderlich ist.

Alle Genehmiger müssen genehmigen (nur Enterprise)

Richte einen Genehmigungsfluss ein, bei dem alle Genehmiger zustimmen müssen, bevor das Dokument in den nächsten Status übergehen kann.

Technisch gesehen führt dieser Knoten Folgendes aus:

  • Sobald ein Genehmiger genehmigt, wird dessen Approver-ID aus der Liste der aktuellen Genehmiger entfernt.

  • Das Dokument wird den weiteren noch ausstehenden Genehmiger zur Genehmigung zugewiesen.

Sobald alle Genehmiger das Dokument genehmigt haben, wird es in den nächsten Schritt im Workflow überführt.

Hat dies deine Frage beantwortet?