Zum Inhalt

ERP-Parametertabellen per GraphQL auslesen

Dieses Dokument beschreibt, wie die wichtigsten Konfigurations- und Parametertabellen der microtech ERP per GraphQL-API ausgelesen werden können.

Diese Parameter sind je Mandant konfigurierbar und bestimmen das Verhalten der microtech ERP (Vorgangsarten, Zahlungsbedingungen, Steuer, Artikelarten etc.). Eine App oder KI/MCP-Integration kann diese Daten nutzen, um die mandantenspezifische Konfiguration zu verstehen, ohne Werte hartzucodieren.

Info


Beachten Sie

Nicht alle Parametertabellen sind in jeder Installation sichtbar. Die Sichtbarkeit hängt von der lizenzierten Ausbaustufe und den freigeschalteten Erweiterungen und Berechtigungen ab. Tabellen, die nicht verfügbar sind, werden nicht ins GraphQL-Schema aufgenommen.

1. Vorgänge und Zwischenbelege

1.1 Vorgangsarten (tblTransactionTypes)

Definiert die verfügbaren Belegarten im System (Angebot, Rechnung, Lieferschein etc.) und ordnet jedem Typ einen Buchungsparameter zu.

Anwendungsfall

Die Vorgangsarten-Tabelle liefert die fldNr jeder Belegart, die als transactionTypeNo-Parameter bei der Vorgangswandlung per fnConvert benötigt wird. Beim Anlegen eines Vorgangs per rowNew bestimmt fldArt(set: {int: XX}) die Belegart -- der übergebene Integer-Wert muss einer gültigen fldNr aus tblTransactionTypes entsprechen. Über fldVBPaGrpBez lässt sich nachvollziehen, welcher Buchungsparameter einer Vorgangsart zugeordnet ist, und fldBenutztKz zeigt, welche Vorgangsarten im Mandanten tatsächlich aktiv sind.

Das Feld fldVgbWdlVogArt zeigt die vorkonfigurierte Wandlungskette: Jede Vorgangsart kennt ihr Standard-Wandlungsziel. So ergibt sich z.B. der typische Ablauf Angebot (15) → AB (20) → Bestellung (30) → Lieferschein (50) → Rechnung (70) → Gutschrift (90). Der Wert 0 bedeutet, dass kein Wandlungsziel hinterlegt ist.

Info

Mutations-Querverweis: fnConvert(transactionTypeNo: XX) erwartet die Vorgangsart-Nummer als Ziel der Wandlung (siehe Vorgänge - Funktionsreferenz, Abschnitt 6). Beim Vorgang anlegen wird fldArt(set: {int: 70}) verwendet (siehe Vorgänge - Funktionsreferenz, Abschnitt 2). Über fldVgbWdlVogArt kann das nächste Wandlungsziel ermittelt werden, ohne den Pfad hartzucodieren.

Siehe auch: Parameter - Vorgangs-Arten | Vorgaben für Wandeln | Standardabläufe Wandeln

Beispiel — Wandlungskette der Vorgangsarten ermitteln:

query {
  tblTransactionTypes {
    rowsRead {
      fldNr                     # Vorgangsart-Nummer (z.B. 70 = Rechnung I)
      fldBez                    # Name der Vorgangsart
      fldVgbWdlVogArt           # Wandlungsziel-Nr. (0 = kein Wandlungsziel)
      fldStdKz(as: BOOLEAN)     # Ist Standard-Vorgangsart
      fldBenutztKz(as: BOOLEAN) # Wird aktiv verwendet
    }
  }
}

Ergebnis

Dieses Beispiel liefert alle Vorgangsarten mit ihrem jeweiligen Wandlungsziel (fldVgbWdlVogArt). Die Wandlungskette liest sich aus den Ergebnissen ab: Jede Vorgangsart verweist per fldVgbWdlVogArt auf die fldNr der Zielvorgangsart. Beispielsweise ergibt sich die Kette Angebot (15) → Auftragsbestätigung (20) → Bestellung vom Kunden (30) → Lieferschein (50) → Rechnung I (70) → Gutschrift (90). Einträge mit fldBenutztKz = false sind deaktiviert, fldVgbWdlVogArt = 0 bedeutet kein Wandlungsziel.

Beispiel — Vorgangsart per Nummer nachschlagen:

query {
  tblTransactionTypes {
    rowRead(kf1Nr: { int: 70 }) {
      fldNr           # Vorgangsart-Nummer
      fldBez          # Name der Vorgangsart
      fldVBPaGrpBez   # Zugeordneter Buchungsparameter
      fldVgbWdlVogArt # Wandlungsziel-Nr.
    }
  }
}

Ergebnis

Dieses Beispiel liefert z.B.: Rechnung I (Nr. 70) mit Buchungsparametergruppe "Rechnung" und Wandlungsziel 90 (Gutschrift). rowRead mit kf1Nr ermöglicht den direkten Schlüsselzugriff auf eine bestimmte Vorgangsart.

1.2 Buchungsparameter (tblPostingParameters)

Definiert die Buchungslogik für verschiedene Vorgangstypen.

Info

Mutations-Querverweis: Die Buchungsparameter steuern das Verhalten von fnPost (Abschnitt 4) und fnConvert (Abschnitt 6) aus der Vorgänge - Funktionsreferenz

Sie bestimmen u.a. Lagerbestandsbewegung, OP-Erstellung, FiBu-Protokoll-Einträge beim Buchen sowie Positionsübernahme, Preisverhalten und Archivierung beim Wandeln.

Siehe auch: Parameter - Buchungsparameter | Buchungsparameter für das Wandeln | Buchungsparameter für das Buchen

Beispiel — Alle Buchungsparameter auslesen:

query {
   tblPostingParameters {
     rowsRead {
       fldVBPaGrpBez          # Gruppenbezeichnung (z.B. "Rechnung", "Lieferschein")
       fldStdKz(as: BOOLEAN)  # Standard-Buchungsparameter
     }
   }
 }

Ergebnis

Dieses Beispiel liefert alle Buchungsparameter-Gruppen. Jede Vorgangsart verweist per fldVBPaGrpBez auf eine dieser Gruppen. fldStdKz kennzeichnet den Standard-Buchungsparameter je Gruppe.


2. Artikel-Parameter

2.1 Einheiten (tblUnitsOfMeasure)

Mengeneinheiten für Artikel (Stück, Meter, Liter etc.).

Anwendungsfall: Beim Anlegen oder Ändern von Artikeln per tblProducts wird die Mengeneinheit über fldEinh gesetzt, dessen gültige Werte aus tblUnitsOfMeasure stammen -- dort liefert fldKuBez das Kürzel (z.B. "Stk", "kg") und fldMgeFak den Mengenfaktor für Verpackungseinheiten. Besonders relevant für E-Rechnungen (XRechnung/ZUGFeRD) ist das Feld fldCodeEinh, das den UN/ECE-Empfehlungscode (Recommendation 20) der Einheit enthält und bei der elektronischen Belegausgabe zwingend erforderlich ist.

Info

Mutations-Querverweis: Am Artikel wird die Einheit per fldEinh(set: {text: "Liter"}) oder validiert per fldEinh(assignUnitOfMeasure: {kf1KuBez: {text: "Liter"}}) gesetzt. Das assign-Argument validiert gegen tblUnitsOfMeasure und ist daher vorzuziehen.

Siehe auch: Einheit & Gewicht | E-Rechnung | Positionserfassung: Einheit

Beispiel — Einheiten mit UN/ECE-Code für E-Rechnung:

query {
   tblUnitsOfMeasure {
     rowsRead {
       fldKuBez                  # Kürzel (Stk, kg, m, ...)
       fldBez                    # Voller Name
       fldCodeEinh               # UN/ECE-Code für E-Rechnung
       fldMgeFak(as: FLOAT)      # Umrechnungsfaktor Menge
       fldBenutztKz(as: BOOLEAN) # Wird aktiv verwendet
     }
   }
 }

Ergebnis

Das Beispiel liefert alle Einheiten; Einträge mit gefülltem fldCodeEinh (z.B. "H87" für Stück, "KGM" für kg, "LTR" für Liter) sind E-Rechnungs-fähig (UN/ECE Recommendation 20).

2.2 Kalkulationsschemen (tblCalculationSchemes)

Definiert, welche Kalkulationsschritte bei der Preisermittlung verwendet werden.

Anwendungsfall: Kalkulationsschemen definieren die Reihenfolge und Art der Kalkulationsschritte (z.B. EK-Preis, Bezugskosten, Handelsspanne, VK-Preis) bei der Artikelpreisermittlung. Per tblCalculationSchemes liest man fldNr, fldBez und fldStdKz aus, um zu erfahren, welche Schemen im Mandanten konfiguriert sind und welches als Standard gilt.

Info

Mutations-Querverweis: Am Artikel wird das Schema per fldVk0_Kalk_Schema(set: {int: 3}) gesetzt (pro VK-Preisgruppe: fldVk0_Kalk_Schema bis fldVk4_Kalk_Schema). Der Integer-Wert entspricht fldNr aus tblCalculationSchemes. Zusätzlich gibt es fldEkKalkSchl für das EK-Kalkulationsschema.

Siehe auch: Einstellungen im Kalkulationsschema | Parameter - Artikel - Kalkulationen

Beispiel — Kalkulationsschemen auslesen:

query {
  tblCalculationSchemes {
    rowsRead {
      fldNr                 # Schema-Nummer
      fldBez                # Bezeichnung
      fldStdKz(as: BOOLEAN) # Standard-Schema
    }
  }
}

Ergebnis

Dieses Beispiel liefert alle konfigurierten Kalkulationsschemen. fldStdKz kennzeichnet das Standard-Schema.

2.3 Zuschlagskalkulationen (tblSurchargeCalculations)

Prozentuale Zuschlagsberechnungen auf Artikelpreise.

Anwendungsfall: Zuschlagskalkulationen legen die prozentualen Zuschlagssätze fest, die bei der Artikelpreisberechnung angewendet werden können. Über tblSurchargeCalculations werden fldNr und fldBez abgefragt, um die verfügbaren Kalkulationsvarianten zu kennen, bevor man sie einem Artikel zuweist. In Kombination mit Zuschlagsartikeln (Artikelart "Zuschlag") werden diese Sätze in der Vorgangserfassung automatisch auf Positionssummen angewendet.

Siehe auch: Zuschlagsartikel

Info

Mutations-Querverweis: Am Artikel wird die Zuschlagskalkulation per fldZKalkSchl(set: {int: 1}) gesetzt, wobei der Wert fldNr aus tblSurchargeCalculations entspricht. Das Hotfield fldZKalkSchlHot (read-only) liefert die zugehörige Bezeichnung. Die berechneten Zuschlagsbeträge pro VK-Preisgruppe stehen in fldVk0_ZuschlBet bis fldVk4_ZuschlBet (ebenfalls read-only).

Beispiel — Zuschlagskalkulationen auslesen:

query {
  tblSurchargeCalculations {
    rowsRead {
      fldNr   # Kalkulationsnummer (diesen Wert in fldZKalkSchl am Artikel setzen)
      fldBez  # Bezeichnung
    }
  }
}

Ergebnis

Das Beispiel liefert die verfügbaren Zuschlagskalkulationen.

2.4 Zuschlagsgruppen (tblSurchargeGroups)

Definiert die Art der Zuschlagsberechnung (prozentual, Festbetrag, Formel).

Anwendungsfall: Zuschlagsgruppen bestimmen die Art der Zuschlagsberechnung -- ob prozentual, als Festbetrag oder per Formel. Per tblSurchargeGroups werden fldNr, fldBez und fldBenutztKz abgefragt, um die aktiv verwendeten Gruppen zu ermitteln und bei der Artikelkonfiguration die passende Berechnungsmethode zuzuordnen. Das Feld fldLtzDat gibt Auskunft darüber, wann die Gruppe zuletzt geändert wurde.

Info

Mutations-Querverweis: Am Artikel wird die Zuschlagsgruppe per fldZuschlGrp(set: {int: 1}) gesetzt, wobei der Wert fldNr aus tblSurchargeGroups entspricht. Zusätzlich kann der Zuschlagsfaktor per fldZuschlFak(set: {double: 1.5}) direkt am Artikel gesetzt werden.

Siehe auch: Zuschlagsartikel

Beispiel — Zuschlagsgruppen und Kalkulationen im Überblick:

query {
  Zuschlagsgruppen: tblSurchargeGroups {
    rowsRead {
      fldNr                     # Gruppen-Nummer
      fldBez                    # Bezeichnung
      fldBenutztKz(as: BOOLEAN) # Wird aktiv verwendet
    }
  }
  Zuschlagskalkulationen: tblSurchargeCalculations {
    rowsRead {
      fldNr  # Kalkulationsnummer
      fldBez # Bezeichnung
    }
  }
}

Ergebnis

Dieses Beispiel liefert beide Tabellen in einem Request: Zuschlagsgruppen definieren die Berechnungsart (prozentual, Festbetrag, Formel), Zuschlagskalkulationen die konkreten Aufschlagsfaktoren.

2.5 Gesperrtgruppen (tblBlockReasons)

Gruppen für das Sperren von Artikeln (z.B. nach Grund oder Bereich).

Anwendungsfall: Gesperrtgruppen definieren benannte Sperrkategorien, über die Artikel für den Verkauf, Einkauf oder andere Prozesse blockiert werden können. Per tblBlockReasons liest man fldNr und fldBez aus, um die verfügbaren Sperrgründe zu kennen.

Info

Mutations-Querverweis: Am Artikel wird die Sperre per fldGspGrp(set: {int: 1}) (Gruppen-Nr. aus tblBlockReasons) und fldGspKz(set: {boolean: true}) aktiviert. Zusätzlich können fldGspDat (Sperrdatum), fldGspAbDat/fldGspBisDat (Sperrzeitraum) und fldGspInfo (Sperrgrund-Text) gesetzt werden.

Siehe auch: Gesperrt-Verwaltung | Artikelerfassung - Kennzeichen

Beispiel — Gesperrtgruppen auslesen:

query {
  tblBlockReasons {
    rowsRead {
      fldNr  # Gruppen-Nummer
      fldBez # Bezeichnung des Sperrgrunds
    }
  }
}

Ergebnis

Dieses Beispiel liefert die verfügbaren Sperrkategorien für Artikel.

2.6 Kataloge (tblCatalogs)

Artikelkataloge zur Gruppierung von Artikeln.

Anwendungsfall: Kataloge dienen der Gruppierung von Artikeln in hierarchische Kategorien -- jeder Artikel kann einem oder mehreren Katalogen zugeordnet werden. Über tblCatalogs werden fldNr, fldBez und fldStdKz abgefragt, um den Hauptkatalog (Vorgabe bei Artikelneuanlage) und alle weiteren verfügbaren Kataloge zu ermitteln.

Beispiel — Artikelkataloge auslesen:

query {
  tblCatalogs {
    rowsRead {
      fldNr                 # Katalog-Nummer
      fldBez                # Katalogname
      fldStdKz(as: BOOLEAN) # Vorgabe-Katalog bei Artikelneuanlage
    }
  }
}

Ergebnis

Dieses Beispiel liefert alle Artikelkataloge. fldStdKz kennzeichnet den Hauptkatalog.

2.7 Frachtgruppen (tblFreightGroups)

Definiert Frachtberechnungsarten für Artikel.

Anwendungsfall: Frachtgruppen steuern die automatische Versandkostenberechnung auf Belegen, indem jedem Artikel eine Frachtberechnungsart zugewiesen wird. Per tblFreightGroups liest man fldNr, fldBez, fldVogAwNr (Ausweisungsnummer auf dem Beleg) und fldArtFrachtB (Berechnungsmethode) aus.

Info

Mutations-Querverweis: Am Artikel wird die Frachtgruppe per fldFrachtGrp(set: {int: 1}) gesetzt, wobei der Integer-Wert fldNr aus tblFreightGroups entspricht.

Siehe auch: Frachtgruppen-Unterstützung | Frachtgruppe den Artikeln zuweisen | Frachtkostenberechnung

Beispiel — Frachtgruppen auslesen:

query {
  tblFreightGroups {
    rowsRead {
      fldNr         # Frachtgruppen-Nummer
      fldBez        # Name
      fldVogAwNr    # Ausweisungsnummer auf dem Beleg
      fldArtFrachtB # Berechnungsmethode
    }
  }
}

Ergebnis

Dieses Beispiel liefert alle Frachtgruppen mit Berechnungsmethode und Belegausweisung.

2.8 Vorbestellungsarten (tblPreOrderTypes)

Arten von Vorbestellungen (z.B. für Gastronomie: Küche, Theke).

Anwendungsfall: Vorbestellungsarten werden verwendet, um verschiedene Vorbestellungstypen (z.B. Küche, Theke, Abholung) zu unterscheiden. Per tblPreOrderTypes werden fldNr und fldBez ausgelesen, um die im Mandanten konfigurierten Typen für die Kassenintegration bereitzustellen.

Info

Siehe auch: microtech Kasse (PoS)

Beispiel — Vorbestellungsarten auslesen:

query {
  tblPreOrderTypes {
    rowsRead {
      fldNr  # Vorbestellungsart-Nummer
      fldBez # Bezeichnung (z.B. Küche, Theke)
    }
  }
}

Ergebnis

Dieses Beispiel liefert die konfigurierten Vorbestellungstypen für Kasse und Gastronomie.

2.9 Rundungsgruppen (tblRoundingGroups)

Rundungsregeln für Preisberechnungen.

Anwendungsfall: Rundungsgruppen definieren die Regeln für die Preisrundung bei Artikeln, z.B. kaufmännisch auf 5 Rappen (Schweiz) oder auf volle Cent. Über tblRoundingGroups werden fldNr, fldBez und fldStdKz ausgelesen, um die Standard-Rundungsgruppe und alle weiteren verfügbaren Rundungsregeln zu kennen.

Mutations-Querverweis: Am Artikel wird die Rundungsgruppe per fldAquoteRdGrp(set: {int: 1}) gesetzt, wobei der Integer-Wert fldNr aus tblRoundingGroups entspricht.

Beispiel — Rundungsgruppen auslesen:

query {
  tblRoundingGroups {
    rowsRead {
      fldNr                 # Gruppen-Nummer
      fldBez                # Bezeichnung
      fldStdKz(as: BOOLEAN) # Standard-Rundungsgruppe
    }
  }
}

Ergebnis

Dieses Beispiel liefert alle Rundungsgruppen. fldStdKz kennzeichnet die Standard-Rundungsregel.


3. Adressen-Parameter

3.1 Adressstatus (tblAddressStatuses)

Klassifiziert Adressen nach ihrem Status (Interessent, Kunde, Lieferant etc.) und weist automatisch Nummernkreise zu.

Anwendungsfall: Der Adressstatus bestimmt bei der Neuanlage per rowNew auf tblAddresses den Nummernkreis der neuen Adresse -- z.B. erhalten Kunden Nummern ab 10000, Lieferanten ab 70000, gesteuert über fldVonAdrNr. Per tblAddressStatuses werden fldBez, fldVonAdrNr und fldStdKz ausgelesen, um zu wissen, welche Status-Kategorien (Interessent, Kunde, Lieferant etc.) konfiguriert sind und welcher als Standard gilt.

Info

Mutations-Querverweis: Bei tblAddresses.rowNew wird der Status per fldStatus(set: {text: "Kunde"}) oder validiert per fldStatus(assignAddressStatus: {kf1Bez: {text: "Kunde"}}) gesetzt. Das System vergibt dann automatisch eine passende fldAdrNr basierend auf fldVonAdrNr des gewählten Status. Mit suppressRelatedUpdates: false (Standard) werden abhängige Felder wie Personengruppe automatisch gesetzt.

Siehe auch: Parameter - Adressen: Status | Status - Berechtigung/Nummernvergabe

Beispiel — Alle Adressstatus mit Nummernkreisen abrufen:

query {
  tblAddressStatuses {
    rowsRead {
      fldBez                # Statusname (Kunde, Lieferant, ...)
      fldVonAdrNr           # Startnummer für neue Adressen
      fldBisAdrNr           # Endnummer des Nummernkreises
      fldStdKz(as: BOOLEAN) # Standard-Status
    }
  }
}

Ergebnis

Jeder Adressstatus definiert einen Nummernkreis (fldVonAdrNr..fldBisAdrNr), aus dem neue Adressen ihre Nummer erhalten. fldStdKz kennzeichnet den Vorgabestatus. Liefert z.B.: "Kunde" (10000–69999, Standard), "Lieferant" (70000–99999).

3.2 Zahlungsbedingungen (tblPaymentTerms)

Definiert die Zahlungskonditionen für Belege und Adressen.

Anwendungsfall: Zahlungsbedingungen werden beim Setzen von fldZahlBed auf Adressen und Vorgängen verwendet. Per tblPaymentTerms liest man fldBez, fldStdKz und fldBenutztKz aus, um die gültigen Zahlungskonditionen des Mandanten zu kennen. Beim Schreiben von fldZahlBed per GraphQL-Mutation werden abhängige Felder wie fldSktoSz1, fldSktoTg1 etc. automatisch gesetzt -- dieses Verhalten kann über den set-Parameter suppressRelatedUpdates: true unterdrückt werden, wenn die Skonto-Felder manuell gesteuert werden sollen (siehe Handbuch Teil 2, Abschnitt 13.1).

Info

Siehe auch: Parameter - Adressen

Beispiel — Alle Zahlungsbedingungen abrufen:

query {
  tblPaymentTerms {
    rowsRead {
      fldBez                    # Name der Zahlungsbedingung
      fldStdKz(as: BOOLEAN)     # Standard-Zahlungsbedingung
      fldBenutztKz(as: BOOLEAN) # Wird aktiv verwendet
    }
  }
}

Ergebnis

fldBenutztKz kennzeichnet aktive Zahlungsbedingungen. Die clientseitige Filterung auf fldBenutztKz = true liefert nur die verwendbaren Einträge. Liefert z.B.: "30 Tage netto", "14 Tage 2 %, 30 Tage Netto", "Vorkasse bei Auftragserteilung".

3.3 Anreden (tblSalutations)

Anredeformen für Adressen und Ansprechpartner.

Anwendungsfall: Anreden werden beim Anlegen von Ansprechpartnern in tblContactPeople verwendet. Per tblSalutations liest man fldBez (z.B. "Herr", "Frau", "Firma") und fldAnrSB (Briefanrede für Serienbriefe, z.B. "Sehr geehrter Herr") aus.

Info

Mutations-Querverweis: Am Ansprechpartner wird die Anrede per fldAnr(set: {text: "Herr"}) oder validiert per fldAnr(assignSalutation: {exactMatch: {byBez: {kf1Bez: {text: "Herr"}}}}) gesetzt. Das Feld existiert auch in Vorgängen als fldReAspAnr (Rechnungs-Ansprechpartner) und fldLiAspAnr (Liefer-Ansprechpartner).

Siehe auch: Parameter - Anreden | Adresserfassung

Beispiel — Anreden auslesen:

query {
  tblSalutations {
    rowsRead {
      fldBez   # Anrede (Herr, Frau, Firma, ...)
      fldAnrSB # Anredeformel für Briefe (z.B. "Sehr geehrter Herr")
    }
  }
}

Ergebnis

Dieses Beispiel liefert alle Anredeformen mit der zugehörigen Briefanrede.

3.4 Verteiler (tblAddressDistributionLists)

Verteilerlisten für Mailings und Kommunikation. Es gibt 5 Varianten je nach Adresstyp:

Tabelle Für
tblAddressDistributionLists Adressen
tblRepresentativeDistributionLists Vertreter
tblEmployeeDistributionLists Mitarbeiter
tblHealthInsuranceDistributionLists Krankenkassen
tblUserDistributionLists Benutzer

Anwendungsfall: Verteiler dienen der Zuordnung von Adressen zu Kommunikationsgruppen für Mailings, Serienbriefe oder Newsletter. Per tblAddressDistributionLists werden fldNr, fldBez und fldBenutztKz ausgelesen, um die konfigurierten Verteilerlisten des Mandanten zu kennen. Neben dem Adress-Verteiler existieren analoge Tabellen für Vertreter (tblRepresentativeDistributionLists), Mitarbeiter (tblEmployeeDistributionLists), Krankenkassen (tblHealthInsuranceDistributionLists) und Benutzer (tblUserDistributionLists).

Info

Siehe auch: Adressen

Beispiel — Alle Verteilerlisten-Typen in einer Abfrage:

query {
  Adressen: tblAddressDistributionLists {
    rowsRead { fldNr fldBez fldBenutztKz(as: BOOLEAN) } # Nr, Bezeichnung, aktiv
  }
  Vertreter: tblRepresentativeDistributionLists {
    rowsRead { fldNr fldBez fldBenutztKz(as: BOOLEAN) }
  }
 Mitarbeiter: tblEmployeeDistributionLists {
    rowsRead { fldNr fldBez fldBenutztKz(as: BOOLEAN) }
  }
  Krankenkassen: tblHealthInsuranceDistributionLists {
    rowsRead { fldNr fldBez fldBenutztKz(as: BOOLEAN) }
  }
  Benutzer: tblUserDistributionLists {
    rowsRead { fldNr fldBez fldBenutztKz(as: BOOLEAN) }
  }
}

Ergebnis

Per Alias werden alle fünf Verteiler-Tabellen in einem einzigen Request abgefragt. Jeder Bereich hat bis zu 32 Verteiler (fldNr 0–31). Liefert z.B.: Adressen-Verteiler "Fax Mailings", "E-Mail Mailings"; Benutzer-Verteiler "Einkauf", "Verkauf".

Anwendungsfall — Verteiler an Anschriften lesen und setzen:

Die Verteilerzuordnung liegt auf tblPostalAddresses (Anschriften) und tblContactPeople (Ansprechpartner) im Feld fldVerteiler. Der Wert ist ein Bitfeld: Jeder Verteiler belegt ein Bit an der Position seiner fldNr. Die Zuordnung von fldNr zum Integer-Wert ist 2^fldNr:

fldNr Bezeichnung (Beispiel) Bit-Wert
0 Fax Mailings 1
1 E-Mail Mailings 2
2 Firmeninformationen 4
3 Vorgang E-Mail 8
4 Versand E-Mail 16

Um mehrere Verteiler gleichzeitig zu setzen, werden die Bit-Werte addiert. Beispiel: "E-Mail Mailings" (Nr 1 → 2) + "Firmeninformationen" (Nr 2 → 4) = 6.

Schritt 1 — Aktuelle Zuordnung einer Anschrift lesen:

query {
  tblPostalAddresses {
    rowRead(kf1AdrNr: { text: "10001", kf2AnsNr: { int: 0 } }) {
      fldNa2
      fldVerteiler  # z.B. 6 → Verteiler Nr 1 und Nr 2 sind aktiv
    }
  }
}

Schritt 2 — Verteiler setzen (z.B. Nr 1 + Nr 2 = 6):

mutation {
  tblPostalAddresses {
    rowModify(kf1AdrNr: { text: "10001", kf2AnsNr: { int: 0 } }) {
      fldVerteiler(set: { int: 6 })
    }
  }
}

Beachten Sie

fldVerteiler(set: { int: 2 }) setzt Verteiler Nr 1 (nicht Nr 2!), weil der Wert ein Bitfeld ist, kein Index. Verteiler Nr 2 hat den Bit-Wert 4.

3.5 Branchen (tblIndustries)

Branchenzuordnung für Adressen.

Anwendungsfall: Branchen ermöglichen die Klassifizierung von Adressen nach Wirtschaftszweigen und werden als Selektions- und Suchkriterium genutzt. Per tblIndustries wird fldBez ausgelesen, um die im Mandanten definierten Branchen zu kennen. Dies ist besonders nützlich für branchenspezifische Mailings oder Auswertungen.

Info

Mutations-Querverweis: An der Adresse wird die Branche per fldBranche(set: {text: "IT"}) oder validiert per fldBranche(assignIndustry: {exactMatch: {byBez: {kf1Bez: {text: "IT"}}}}) gesetzt.

Siehe auch: Parameter - Branchen | Branchensuche

Beispiel — Branchen auslesen:

query {
  tblIndustries {
    rowsRead {
      fldBez # Branchenbezeichnung
    }
  }
}

Ergebnis

Dieses Beispiel liefert alle im Mandanten definierten Branchen.


4. Steuer und Finanzen

4.1 Umsatzsteuer (tblValueAddedTaxTypes)

Steuerschlüssel mit Sätzen, DATEV-Zuordnung und E-Rechnungs-Konfiguration.

Anwendungsfall: Die Steuerschlüssel-Tabelle liefert die fldStSchl-Nummern, die beim Setzen von Steuerschlüsseln an Artikeln und Vorgangspositionen benötigt werden. Sie enthält den Steuersatz (fldSz), die DATEV-Zuordnung (fldDatevSSchl) für den Buchhaltungsexport und die USt-Voranmeldungszeile (fldUStAnmNr). Für E-Rechnungen (XRechnung/ZUGFeRD) ist der korrekte Steuerschlüssel essentiell, da er in die strukturierten Rechnungsdaten einfließt.

Info

Mutations-Querverweis: Bei Vorgangspositionen kann der Steuerschlüssel über fldStSchl(set: {int: XX}) gesetzt werden. Betragsgruppen (aco...) unterstützen den gezielten Zugriff auf einzelne Steuersätze per aceByTaxCode(taxCode: XX), um Brutto-/Nettobeträge pro Steuerschlüssel zu setzen (siehe Handbuch Teil 2, Abschnitt 13.6).

Siehe auch: Parameter - Umsatzsteuer | Steuerschlüssel im Artikel | E-Rechnung

Beispiel — Einzelnen Steuerschlüssel per kf1StSchl nachschlagen:

query {
  tblValueAddedTaxTypes {
    rowRead(kf1StSchl: { int: 3 }) {
      fldStSchl              # Steuerschlüssel-Nummer
      fldBez                 # Name (z.B. "Mehrwertsteuer 19%")
      fldSz(as: FLOAT)       # Steuersatz in Prozent
      fldStSuf               # Kürzel (M19, V7, ...)
      fldDatevSSchl          # DATEV-Steuerschlüssel
    }
  }
}

Ergebnis

Schlägt den Steuerschlüssel 3 (Mehrwertsteuer 19 %) direkt per Schlüsselzugriff nach. fldStSuf ist das Steuersuffix für Vorgänge, fldDatevSSchl der DATEV-Steuerschlüssel.

4.2 Fremdwährungen (tblCurrencies)

Konfigurierte Fremdwährungen mit Wechselkursen.

Anwendungsfall: Die Fremdwährungstabelle liefert die verfügbaren Währungen mit ihren ISO-Codes (fldISOBez) und aktuellen Wechselkursen (fldFrWFak, fldBaWFak). Dies wird benötigt, um Fremdwährungsbelege korrekt anzulegen und zu prüfen, welche Währungen im Mandanten konfiguriert sind. Die Basiswährung (fldBasisWKz = true) kennzeichnet die Hauptwährung des Mandanten.

Info

Mutations-Querverweis: Beim Anlegen oder Ändern eines Vorgangs wird die Währung über fldWaehr(assignCurrency: {kf1KuBez: {text: "US-$"}}) gesetzt. Das assign-Argument sucht anhand der Kurzbezeichnung (fldKuBez) in tblCurrencies und setzt den ISO-Code (fldISOBez, z.B. "USD") als Feldwert. Alternativ kann der ISO-Code direkt per fldWaehr(set: {text: "USD"}) gesetzt werden — der Wert muss dann einem fldISOBez aus tblCurrencies entsprechen (nicht fldKuBez). Siehe Vorgänge - Funktionsreferenz, Abschnitt 2 und Handbuch Teil 2, Abschnitt 13.1.

Siehe auch: Parameter - Fremdwährungen | Artikel-Zusatzpreise in Fremdwährung

Beispiel — Währungen mit Umrechnungsfaktoren und Aktualisierungsdatum:

query {
  tblCurrencies {
    rowsRead {
      fldKuBez                  # Währungskürzel
      fldBez                    # Voller Name
      fldISOBez                 # ISO 4217 Code
      fldFrWFak(as: FLOAT)      # Fremdwährungs-Umrechnungsfaktor
      fldBaWFak(as: FLOAT)      # Basiswährungs-Faktor
      fldBasisWKz(as: BOOLEAN)  # Ist Basiswährung
      fldLtzDat(as: TEXT)       # Letzte Kursänderung
    }
  }
}

Ergebnis

Die Basiswährung hat fldBasisWKz = true (hier: Euro). fldFrWFak und fldBaWFak sind die Fremd- bzw. Basis-Währungsfaktoren für die Umrechnung, fldLtzDat das Datum der letzten Kursanpassung.

4.3 Mahnstufen (tblDunningLevels)

Eskalationsstufen für das Mahnwesen bei offenen Posten.

Anwendungsfall: Die Mahnstufen-Tabelle zeigt die konfigurierten Eskalationsstufen des Mahnwesens mit Karenzzeit (fldMaTge), Zinssatz (fldZiSz) und Mahngebühren (fldMaGeb).

Beispiel — Mahnstufen mit Karenzzeiten und Zinssätzen:

query {
  tblDunningLevels {
    rowsRead {
      fldMaStNr           # Mahnstufe (1, 2, 3, ...)
      fldMaTge            # Tage nach Fälligkeit
      fldZiSz(as: FLOAT)  # Verzugszinsen in Prozent
      fldMaGeb(as: TEXT)   # Gebühr pro Mahnung
    }
  }
}

Ergebnis

Zeigt die Eskalationskette: fldMaStNr ist die Mahnstufe, fldMaTge die Karenzzeit in Tagen, fldZiSz der Verzugszinssatz und fldMaGeb die Mahngebühr.

4.4 Zahlungsarten (tblPaymentMethods)

Definiert die im Zahlungsverkehr verfügbaren Zahlungswege.

Anwendungsfall: Die Zahlungsarten-Tabelle listet die im Zahlungsverkehr verfügbaren Zahlungswege (Überweisung, Lastschrift, Bar, etc.).

Beispiel — Zahlungsarten auslesen:

query {
  tblPaymentMethods {
    rowsRead {
      fldNr                     # Zahlungsart-Nummer
      fldBez                    # Name der Zahlungsart
      fldBenutztKz(as: BOOLEAN) # Wird aktiv verwendet
    }
  }
}

Ergebnis

Liefert die im Zahlungsverkehr verfügbaren Zahlungswege.

4.5 Rohstoffkurse (tblCommodityPrices)

Rohstoffpreise für materialabhängige Kalkulation.

Anwendungsfall: Die Rohstoffkurs-Tabelle liefert aktuelle Kurse für materialabhängige Kalkulationen (z.B. Gold, Silber, Kupfer). Artikel werden über fldRskNr (Rohstoffkursnummer, referenziert fldNr aus tblCommodityPrices) mit einem Kurs verknüpft. Zusätzlich muss fldArtikelArt auf 110 (Rohstoffkurs-Artikel) gesetzt sein. Über fldVk0_RohSz bis fldVk4_RohSz werden Zuschlagssätze pro VK-Preisgruppe definiert, die resultierende Beträge in fldVk0_RohBet etc. erzeugen.

Info

Mutations-Querverweis: Am Artikel wird der Rohstoffkurs per fldRskNr(set: {int: 1}) zugewiesen, wobei der Wert fldNr aus tblCommodityPrices entspricht. Zusätzlich muss fldArtikelArt auf 110 (Rohstoffkurs-Artikel) stehen. Über fldVk0_RohSz bis fldVk4_RohSz werden Zuschlagssätze pro VK-Preisgruppe definiert, die resultierenden Beträge stehen in fldVk0_RohBet etc. (read-only). Die Tabelle tblCommodityPrices selbst ist per GraphQL nur lesbar -- Kursanpassungen erfolgen über die Applikation oder die Prozessautomatisierung.

Siehe auch: Parameter - Rohstoffkurse | Artikelart Rohstoffkurs | Rohstoffkurse automatisch aktualisieren

Beispiel — Rohstoffpreise mit letztem Aktualisierungszeitpunkt:

query {
  tblCommodityPrices {
    rowsRead {
      fldNr              # Rohstoff-Nummer
      fldNa              # Kurzname (z.B. "gold")
      fldBez             # Volle Bezeichnung
      fldWert(as: TEXT)  # Aktueller Kurs
      fldDatZt(as: TEXT) # Zeitpunkt der letzten Aktualisierung
    }
  }
}

Ergebnis

Liefert alle gepflegten Rohstoffkurse. fldDatZt zeigt den Zeitpunkt der letzten Kursanpassung — relevant für die Kalkulationsaktualität.


5. Logistik und Versand

5.1 Kommissionierstrategien (tblPickingStrategies)

Strategien für die Kommissionierung im Lager.

Anwendungsfall: Kommissionierstrategien steuern, wie Vorgangspositionen zu Picklisten gruppiert werden. Per tblPickingStrategies lassen sich die konfigurierten Strategien auslesen, um die zugeordnete Vorgangsart (fldVogArt) und Kommissionierungsart (fldKommiArt, z.B. auftragsbezogen, Ein-Posten, Sammelkommissionierung) zu ermitteln.

Siehe auch: Kommissionierstrategien

Beispiel — Kommissionierstrategien mit Vorgangsarten abgleichen:

query {
  Kommissionierung: tblPickingStrategies {
    rowsRead {
      fldNr                     # Strategie-Nummer
      fldBez                    # Bezeichnung
      fldKommiArt               # Kommissionierungsart
      fldVogArt                 # Zugeordnete Vorgangsart-Nr.
      fldBenutztKz(as: BOOLEAN) # Wird aktiv verwendet
    }
  }
  Vorgangsarten: tblTransactionTypes {
    rowsRead {
      fldNr  # Vorgangsart-Nummer
      fldBez # Name
    }
  }
}

Ergebnis

Fragt Kommissionierstrategien und Vorgangsarten in einem einzigen Request ab. Das Feld fldVogArt der Kommissionierstrategie verweist auf die fldNr einer Vorgangsart.

5.2 Logistik-Arbeitsplätze (tblLogisticWorkstations)

Arbeitsplätze für Lager- und Versandprozesse.

Anwendungsfall: Logistik-Arbeitsplätze definieren die Konfiguration der Lager- und Versandstationen, einschliesslich zugeordneter Vorgangsarten, Einstellungen für Scan-Verhalten und Berechtigungsgruppen.

Beispiel — Logistik-Arbeitsplätze auslesen:

query {
  tblLogisticWorkstations {
    rowsRead {
      fldNr                     # Arbeitsplatz-Nummer
      fldBez                    # Bezeichnung
      fldBenutztKz(as: BOOLEAN) # Wird aktiv verwendet
    }
  }
}

Ergebnis

Liefert die konfigurierten Lager- und Versandstationen.

5.3 Versandarten (tblShippingTypes)

Versanddienstleister und -methoden mit Paketnummernverwaltung.

Anwendungsfall: Versandarten definieren die konfigurierten Versanddienstleister und -methoden mit Paketnummernverwaltung. Per tblShippingTypes lassen sich Versender (fldVersender), Versandmethode (fldVsdArt) und die nächste laufende Paketnummer (fldNAbsBelegNr) auslesen. Das Feld fldBenutztKz zeigt an, welche Versandarten aktiv sind.

Info

Mutations-Querverweis: Am Vorgang wird die Versandart per fldVsdArt(set: {int: 1}) gesetzt, wobei der Integer-Wert fldNr aus tblShippingTypes entspricht. Das Feld existiert auch in tblAddresses als Vorgabewert für neue Vorgänge dieser Adresse.

Siehe auch: Parameter: Versandarten | Versandarten - Allgemein

Beispiel — Alle aktiven Versandarten abrufen:

query {
  tblShippingTypes {
    rowsRead {
      fldNr                     # Versandart-Nummer
      fldBez                    # Vollständiger Name
      fldVersender              # Dienstleister-Name
      fldVsdArt                 # Versandmethode
      fldBenutztKz(as: BOOLEAN) # Wird aktiv verwendet
    }
  }
}

Ergebnis

Liefert alle Versandarten mit Versender und Versandartbezeichnung. Die Kombination fldVersender + fldVsdArt ergibt die vollständige Bezeichnung (z.B. "UPS" + "Standard/Pakettarif" = "UPS Standard/Pakettarif" in fldBez). Deaktivierte Versandarten erkennt man an fldBenutztKz = false.

5.4 Stammlager (tblMasterWarehouses)

Zentrale Lagerdefinitionen, die für alle Artikel gelten.

Anwendungsfall: Stammlager sind zentrale Lager-Vorlagen: Ein Stammlager wird einmal definiert und automatisch allen Artikeln zugeordnet. Änderungen an Bezeichnung oder Anschrift eines Stammlagers wirken sich auf alle Artikeldatensätze aus. Per tblMasterWarehouses können die konfigurierten Stammlager mit Lagerkürzel (fldLagNr), Bezeichnung (fldBez) und Lagerplatzverwaltungs-Status (fldLagPlatzKz) ausgelesen werden. Nicht zu verwechseln mit tblWarehouses, das die konkreten Lagerzuordnungen pro Artikel enthält.

Info

Mutations-Querverweis: Im Artikelstamm setzt fldLagNr(set: {text: "HL-1"}) das Vorgabe-Lager. Das assignWarehouse-Argument validiert gegen tblWarehouses (Lager pro Artikel) — da Stammlager dort automatisch für jeden Artikel existieren, können auch Stammlager-Kürzel aus tblMasterWarehouses per assignWarehouse zugewiesen werden.

Siehe auch: Parameter: Stammlager | Lagerplatzverwaltung

Beispiel — Stammlager mit Lagerplatz-Status abrufen:

query {
  tblMasterWarehouses {
    rowsRead {
      fldLagNr                    # Lager-Kürzel (z.B. "HL-1")
      fldBez                      # Lagername
      fldLagPlatzKz(as: BOOLEAN)  # Lagerplatzverwaltung aktiv
    }
  }
}

Ergebnis

Liefert alle Stammlager. Lager mit aktivierter Lagerplatzverwaltung erfordern bei Lagerbuchungen die Angabe eines konkreten Lagerplatzes.

5.5 Stellplatzgrößen (tblWarehouseSlotSizes)

Größendefinitionen für Lagerplätze (Breite, Höhe, Tiefe, Gewicht).

Anwendungsfall: Stellplatzgrößen definieren die physischen Abmessungen und Kapazitäten von Lagerplätzen (Breite, Höhe, Tiefe, Maximalgewicht). Per tblWarehouseSlotSizes können die konfigurierten Größenkategorien (fldSpgNr, fldBez) abgefragt werden, wobei fldGrpKz anzeigt, ob es sich um eine Gruppendefinition handelt, die mehrere Einzelgrößen zusammenfasst.

Info

Siehe auch: Stellplatzgroessen | Regaleinteilung

Beispiel — Stellplatzgrößen auslesen:

query {
  tblWarehouseSlotSizes {
    rowsRead {
      fldSpgNr              # Stellplatzgrößen-Nummer
      fldBez                # Bezeichnung
      fldGrpKz(as: BOOLEAN) # Gruppendefinition
    }
  }
}

Ergebnis

Liefert die Größenkategorien für Lagerplätze. fldGrpKz zeigt an, ob es sich um eine Gruppendefinition handelt.


6. Projekte

6.1 Projektarten (tblProjectTypes)

Klassifizierung von Projekten.

Anwendungsfall: Projektarten klassifizieren Projekte nach ihrem Typ (z.B. Kundenprojekt, Internes Projekt, Servicevertrag). Per tblProjectTypes lassen sich die konfigurierten Arten mit Nummer (fldNr), Bezeichnung (fldBez) und Standard-Kennzeichen (fldStdKz) auslesen.

Info

Mutations-Querverweis: Am Projekt wird die Art per fldArt(set: {int: 1}) gesetzt, wobei der Integer-Wert fldNr aus tblProjectTypes entspricht.

Siehe auch: Projektverwaltung: Projektart

Beispiel — Projektarten auslesen:

query {
  tblProjectTypes {
    rowsRead {
      fldNr                 # Projektart-Nummer
      fldBez                # Bezeichnung
      fldStdKz(as: BOOLEAN) # Standard-Projektart
    }
  }
}

Ergebnis

Liefert alle Projektart-Klassifizierungen. fldStdKz kennzeichnet die Standard-Projektart.

6.2 Projektstatus (tblProjectStates)

Statuswerte für den Projektfortschritt mit definierten Übergängen.

Anwendungsfall: Der Projektstatus bildet eine Workflow-Zustandsmaschine ab, in der jeder Status über fldStdFolgePrjSts seinen definierten Folgestatus kennt. Per tblProjectStates können die verfügbaren Zustände (fldNr, fldBez) und deren Übergänge ausgelesen werden, um den Workflow-Fortschritt eines Projekts nachzuvollziehen.

Info

Mutations-Querverweis: Am Projekt wird der Status per fldPrjSts(set: {int: 30}) gesetzt (z.B. 10 = "Zur Bearbeitung", 30 = "In Bearbeitung", 50 = "Geschlossen"). Projekte können per fnMoveToArchive in tblProjectsArchive verschoben und per fnRestoreToProjects wiederhergestellt werden.

Siehe auch: Projektstatus ändern | Archiv-Funktionen

Beispiel — Projektstatus-Workflow abrufen:

query {
  tblProjectStates {
    rowsRead {
      fldNr                     # Status-Nummer
      fldBez                    # Statusname
      fldStdFolgePrjSts         # Nächster Status im Workflow
      fldStdKz(as: BOOLEAN)     # Standard-Status
      fldBenutztKz(as: BOOLEAN) # Wird aktiv verwendet
    }
  }
}

Ergebnis

Die Workflow-Kette ergibt sich aus fldStdFolgePrjSts, das auf die fldNr des Folgestatus verweist: „Zur Bearbeitung" (10) → „Anerkannt" (20) → „In Bearbeitung" (30) → „Geschlossen" (50). Der Status „Wartet" (40) führt zurück zu „In Bearbeitung" (30).

6.3 Projekt-Checklisten (tblProjectChecklists)

Vordefinierte Checklisten-Vorlagen für Projekte.

Anwendungsfall: Projekt-Checklisten sind vordefinierte Vorlagen, die Projekten zugeordnet werden können, um standardisierte Arbeitsschritte abzubilden. Per tblProjectChecklists lassen sich die konfigurierten Checklisten-Vorlagen (fldNr, fldBez, fldBenutztKz) auslesen, um bei der Projektanlage oder -bearbeitung die passende Checkliste zuzuordnen.

Info

Siehe auch: Projekt-Checklisten

Beispiel — Projekt-Checklisten auslesen:

query {
  tblProjectChecklists {
    rowsRead {
      fldNr                     # Checklisten-Nummer
      fldBez                    # Bezeichnung
      fldBenutztKz(as: BOOLEAN) # Wird aktiv verwendet
    }
  }
}

Ergebnis

Liefert die verfügbaren Checklisten-Vorlagen für Projekte.


7. Dokumente

7.1 Dokumentenarten (tblDocumentTypes)

Klassifiziert Dokumente im DMS (Eingangsrechnung, Ausgangsrechnung etc.).

Anwendungsfall: Dokumentenarten klassifizieren Dokumente im DMS-Modul (z.B. Eingangsrechnung, Ausgangsrechnung, Vertrag). Per tblDocumentTypes können die konfigurierten Arten (fldNr, fldBez) und insbesondere der Vorgabe-Dokumentenstatus (fldVgbDokSts) ausgelesen werden, der definiert, welchen Status ein neu erfasstes Dokument dieser Art automatisch erhält.

Info

Mutations-Querverweis: Am Dokument wird die Art per fldArt(set: {int: 20}) gesetzt (z.B. 10 = "Sonstige", 20 = "Eingangsrechnung", 30 = "Ausgangsrechnung"). Der Wert entspricht fldNr aus tblDocumentTypes.

Siehe auch: DMS-Konfiguration: Dokumentenarten

Beispiel — Dokumentenarten mit Vorgabe-Status:

query {
  tblDocumentTypes {
    rowsRead {
      fldNr                 # Dokumentenart-Nummer
      fldBez                # Name
      fldVgbDokSts          # Vorgabe-Dokumentenstatus
      fldStdKz(as: BOOLEAN) # Standard-Dokumentenart
    }
  }
}

7.2 Dokumentenstatus (tblDocumentStates)

Workflow-Status für Dokumente mit definierten Übergängen.

Anwendungsfall: Dokumentenstatus bilden den Prüf- und Freigabe-Workflow im DMS ab. Per tblDocumentStates lässt sich die Workflow-Kette über fldStdFolgeDokSts (Folgestatus) auslesen -- ein typischer Ablauf ist: Unbelegt → Formal prüfen → Inhaltlich prüfen → Buchungsfreigabe → Verarbeitet.

Info

Mutations-Querverweis: Am Dokument wird der Status per fldDokSts(set: {int: 200}) gesetzt (z.B. 10 = "Unbelegt", 200 = "Neu (formal prüfen)", 201 = "Inhaltlich prüfen", 202 = "Buchungsfreigabe prüfen", 203 = "Verarbeitet"). Der Wert entspricht fldNr aus tblDocumentStates.

Siehe auch: DMS-Konfiguration: Dokumentenstatus

Beispiel — Dokumentenstatus-Workflow abrufen:

query {
  tblDocumentStates {
    rowsRead {
      fldNr                     # Status-Nummer
      fldBez                    # Statusname
      fldStdFolgeDokSts         # Nächster Status im Workflow
      fldBenutztKz(as: BOOLEAN) # Wird aktiv verwendet
    }
  }
}

Ergebnis

Die Workflow-Kette ergibt sich aus fldStdFolgeDokSts: „Neu (formal prüfen)" (200) → „Inhaltlich prüfen" (201) → „Buchungsfreigabe prüfen" (202) → „Verarbeitet" (203). fldVgbDokSts der Dokumentenart (7.1) verweist auf fldNr des Dokumentenstatus als Vorgabe-Anfangsstatus.


8. Kontakte

8.1 Kommunikationsarten (tblCommunicationTypes)

Definiert die verfügbaren Kommunikationskanäle.

Anwendungsfall: Kommunikationsarten definieren die verfügbaren Kanäle für die Kontakterfassung in tblContacts (z.B. Telefonat, E-Mail, Brief, Besuch). Per tblCommunicationTypes können die konfigurierten Kanäle (fldNr, fldBez) und deren Richtung (fldKomRicht -- gehend oder kommend) ausgelesen werden. fldBenutztKz zeigt an, welche Arten aktiv verfügbar sind.

Info

Mutations-Querverweis: Am Kontakt wird die Art per fldKomArt(set: {int: 10}) gesetzt (z.B. 10 = "E-Mail", 20 = "Telefon", 30 = "Brief", 50 = "Telefax"). Die Richtung wird per fldKomRicht(set: {int: 1}) gesetzt (1 = gehend, 2 = gehend und kommend).

Siehe auch: Parameter: Kommunikationsarten | Kontakt: Kommunikationsart und Richtung

Beispiel — Kommunikationsarten mit Richtung abrufen:

query {
  tblCommunicationTypes {
    rowsRead {
      fldNr                     # Kommunikationsart-Nummer
      fldBez                    # Name des Kanals
      fldKomRicht               # Richtung (1=gehend, 2=gehend und kommend)
      fldBenutztKz(as: BOOLEAN) # Wird aktiv verwendet
    }
  }
}

Ergebnis

fldKomRicht unterscheidet die Kommunikationsrichtung: 1 = gehend, 2 = gehend und kommend. So lässt sich z.B. filtern, welche Kommunikationsarten für eingehende Vorgänge relevant sind. Liefert z.B.: "E-Mail" (gehend), "Telefon" (gehend/kommend), "Brief" (gehend), "Telefax" (gehend).


9. Produktion

9.1 Produktion-Arbeitsplätze (tblProductionWorkstations)

Arbeitsplätze für Fertigungsprozesse.

Anwendungsfall: Produktion-Arbeitsplätze definieren die konfigurierten Stationen für Fertigungsprozesse im Produktionsmodul. Per tblProductionWorkstations können die verfügbaren Arbeitsplätze (fldNr, fldBez, fldBenutztKz) ausgelesen werden, um bei der Produktionsplanung und Zeiterfassung den korrekten Arbeitsplatz zuzuordnen. In den Buchungsparametern kann pro Vorgangsart ein Produktions-Arbeitsplatz hinterlegt werden.

Siehe auch: Produktion: Arbeitsplätze | Buchungsparameter: Produktion-Arbeitsplatz

Beispiel — Produktion-Arbeitsplätze auslesen:

query {
  tblProductionWorkstations {
    rowsRead {
      fldNr                     # Arbeitsplatz-Nummer
      fldBez                    # Bezeichnung
      fldBenutztKz(as: BOOLEAN) # Wird aktiv verwendet
    }
  }
}

Ergebnis

Liefert die konfigurierten Fertigungsarbeitsplätze.


10. Feldnamen per Introspection ermitteln

Alle verfügbaren Felder (Name und Beschreibung) einer Tabelle können per Introspection abgefragt werden:

# Beispiel: Felder der Umsatzsteuer-Tabelle
query {
  __type(name: "ValueAddedTaxTypeSlowAnyFields") {
    enumValues { name description }
  }
}

Alle verfügbaren Tabellen mit deren Beschreibung auflisten

query {
  __type(name: "Query") {
    fields { name description }
  }
}

Dies listet alle tbl...-Einträge auf, die per GraphQL erreichbar sind.

Datenbank-Zuordnung ermitteln (Mandant oder Global)

Per Introspection kann geprüft werden, ob eine Tabelle in der Mandanten-Datenbank (dbaMand) oder global (dbaGlobal, dbaProgramm) liegt:

query {
  Vorgangsarten: __type(name: "TransactionTypesTableQueryRead") {
    anyExtensionValue(name: "dbAlias")
  }
  Buchungsparameter: __type(name: "PostingParametersTableQueryRead") {
    anyExtensionValue(name: "dbAlias")
  }
  # ... weitere Tabellen analog: {PluralName}TableQueryRead
}

Die Namenskonvention für den Typ ist {PluralName}TableQueryRead. Mögliche Werte: dbaMand (Mandanten-DB), dbaGlobal (globale DB), dbaProgramm (Programm-DB).