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
-
Grundlagen / Voraussetzungen der GraphQL-Abfragen (Paginierung, Filter, Sortierung) finden Sie im Hilfe-Artikel GraphQL Entwickler Dokumentation - Abfragen (Queries).
-
Für Felder die als Dropdown dargestellt werden (z.B. Artikelarten) kann
fnLookup { choices(for: ...) { text value } }verwendet werden (siehe Abschnitt 10.3).
- 1. Vorgänge und Zwischenbelege
- 1.1 Vorgangsarten (
tblTransactionTypes) - 1.2 Buchungsparameter (
tblPostingParameters) - 2. Artikel-Parameter
- 2.1 Einheiten (
tblUnitsOfMeasure) - 2.2 Kalkulationsschemen (
tblCalculationSchemes) - 2.3 Zuschlagskalkulationen (
tblSurchargeCalculations) - 2.4 Zuschlagsgruppen (
tblSurchargeGroups) - 2.5 Gesperrtgruppen (
tblBlockReasons) - 2.6 Kataloge (
tblCatalogs) - 2.7 Frachtgruppen (
tblFreightGroups) - 2.8 Vorbestellungsarten (
tblPreOrderTypes) - 2.9 Rundungsgruppen (
tblRoundingGroups) - 3. Adressen-Parameter
- 3.1 Adressstatus (
tblAddressStatuses) - 3.2 Zahlungsbedingungen (
tblPaymentTerms) - 3.3 Anreden (
tblSalutations) - 3.4 Verteiler (
tblAddressDistributionLists) - 3.5 Branchen (
tblIndustries) - 4. Steuer und Finanzen
- 4.1 Umsatzsteuer (
tblValueAddedTaxTypes) - 4.2 Fremdwährungen (
tblCurrencies) - 4.3 Mahnstufen (
tblDunningLevels) - 4.4 Zahlungsarten (
tblPaymentMethods) - 4.5 Rohstoffkurse (
tblCommodityPrices) - 5. Logistik und Versand
- 5.1 Kommissionierstrategien (
tblPickingStrategies) - 5.2 Logistik-Arbeitsplätze (
tblLogisticWorkstations) - 5.3 Versandarten (
tblShippingTypes) - 5.4 Stammlager (
tblMasterWarehouses) - 5.5 Stellplatzgrößen (
tblWarehouseSlotSizes) - 6. Projekte
- 6.1 Projektarten (
tblProjectTypes) - 6.2 Projektstatus (
tblProjectStates) - 6.3 Projekt-Checklisten (
tblProjectChecklists) - 7. Dokumente
- 7.1 Dokumentenarten (
tblDocumentTypes) - 7.2 Dokumentenstatus (
tblDocumentStates) - 8. Kontakte
- 8.1 Kommunikationsarten (
tblCommunicationTypes) - 9. Produktion
- 9.1 Produktion-Arbeitsplätze (
tblProductionWorkstations) - 10. Feldnamen per Introspection ermitteln
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.
Info
Siehe auch: Einrichten der Kataloge in den Parametern | Artikelkataloge in den Stammdaten
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.
Info
Siehe auch: Parameter - Artikel: Rundungsgruppe
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).
Info
Siehe auch: Parameter - Mahnstufen | OP-Verwaltung und Mahnwesen
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.).
Info
Siehe auch: Zahlungsverkehr | Kasse - Belegarten und Zahlarten
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.
Info
Siehe auch: Logistik-Arbeitsplätze | Buchungsparameter: Logistik-Arbeitsplatz
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).