Bekannte Einschränkungen der SelectLine-API

Bei einigen Ressourcen bleibt eine Listenoption ohne Wirkung: Sie tragen einen Suchbegriff ein, die Abfrage läuft ohne Fehler durch — und liefert trotzdem alle Datensätze. Das ist kein Fehler der Node.

Die Node schickt jeden Parameter genau so an die SelectLine-API, wie deren eigene Schnittstellenbeschreibung (Swagger) ihn vorgibt. Ob der Server ihn dann auch auswertet, entscheidet ausschließlich die API. Tut er es nicht, kommt keine Fehlermeldung zurück — die Abfrage sieht erfolgreich aus, der Parameter verpufft still.

Zuständigkeit

Die auf dieser Seite aufgeführten Punkte liegen im API-Dienst slmobileApi der SelectLine Software GmbH und können nur vom Hersteller behoben werden. Sie sind keine Fehler der SelectLine-Node und auch nicht durch ein Node-Update behebbar: Es gibt keinen anderen Weg, die Parameter zu übermitteln — sie werden serverseitig nicht ausgewertet.

Wenn Sie einen dieser Punkte benötigen, wenden Sie sich bitte an uns — nicht direkt an SelectLine. Wir analysieren den Fall, grenzen ihn gegen Konfiguration und Bedienung ab und geben ihn, wenn er sich bestätigt, mit den Nachweisen an SelectLine weiter. Siehe Fall an uns melden.

Für den praktischen Umgang damit gibt es Umgehungen in n8n — siehe Was Sie stattdessen tun können.

Wie das geprüft wurde

Geprüft am 29.09.2026 gegen die slmobileApi (Spezifikationsstand v1) im Mandanten SL_MWAWI: 120 GET-Endpunkte, 801 Abfragen, ausschließlich lesend.

Die Prüfung stellt jeden Parameter auf die Probe, statt nur zu schauen, ob der Aufruf gelingt:

Parameter	Prüfung	Erwartung
Einträge	Einträge = 1	genau 1 Datensatz
Seitenzahl	Seite 0 gegen Seite 1	verschiedene Datensätze
Suchen nach	ein Begriff, der im Bestand nicht vorkommen kann	0 Datensätze
Suchen in	ein Wert, der nur in Feld A steht, gesucht nur in Feld B	0 Datensätze
Sortieren nach	aufsteigend gegen absteigend	verschiedene Reihenfolge, und tatsächlich sortiert
Filter	Ausdruck ohne möglichen Treffer / Ausdruck auf einen echten Wert	0 Datensätze / nur passende Datensätze

Kommt bei der Suche nach einem unmöglichen Begriff unverändert der vollständige Bestand zurück, ist damit belegt, dass der Parameter nicht ausgewertet wird — unabhängig davon, wie viele Datensätze der Mandant enthält.

Das Ergebnis im Überblick: 262 Prüfungen bestanden, 33 Parameter wirkungslos, 28 Aufrufe mit Serverfehler, 3 Sortierungen auffällig. Die Listenoptionen funktionieren also bei der großen Mehrheit der Ressourcen — Kunden, Belege, Lieferanten, Projekte und die übrigen Stammdaten sind nicht betroffen.

„Suchen nach” wird nicht ausgewertet

Bei diesen Ressourcen liefert ein Suchbegriff unverändert alle Datensätze:

Ressource	Endpunkt
Lager	/Warehouses, /Warehouses/Stocks, /Warehouses/{lager}/Stocks, /Warehouses/{lager}/StoragePlaces, /Warehouses/{lager}/StoragePlaces/{platz}/Stocks
Artikel (Bestände)	/Articles/Stock
Belege	/DocumentPositions
Inventur	/Inventories, /Inventories/{nummer}/Warehouses, /Inventories/{nummer}/Warehouses/{lager}/Articles
Produktion	/ProductionOrders, /ProductionSteps, /ProductionOrders/StoredQuantities, /ProductionOrders/{id}/Articles, /ProductionOrders/{id}/ProductionRequirements, /ProductionOrders/{id}/ProductionSteps, /ProductionOrders/{id}/ProductionSteps/{schritt}/Articles
Produktionssteuerung	/ProductionControl/Jobs
Ressourcen	/OperatingResources, /AlternativeResources
Seriennummern	/SerialNumbers
Unterschriften	/Signatures
Mandanten	/Tenants

„Filter” wird nicht ausgewertet

Hier bleibt auch der präzise Filterausdruck ohne Wirkung — geprüft mit einem Ausdruck, der niemanden treffen kann, und mit einem Ausdruck auf einen tatsächlich vorhandenen Wert. Beide liefern den vollständigen Bestand:

Ressource	Endpunkt	Beobachtung
Artikelgruppen	/ArticleGroups	Number EQ '100' liefert alle 16 Gruppen, davon 15 mit anderer Nummer
Preisgruppen	/PriceGroups	Number EQ '1' liefert alle 9 Preisgruppen
Mandanten	/Tenants	Filter ohne Wirkung

Mandanten: alle Listenoptionen ohne Wirkung

/Tenants ist der einzige Endpunkt, bei dem keine Listenoption greift: Einträge, Seitenzahl, Suchen nach, Suchen in, Sortieren nach und Filter liefern durchgehend dieselbe unveränderte Liste. Einträge = 1 gab 6 Mandanten zurück.

In der Praxis wenig einschränkend, weil die Mandantenliste kurz ist — Sie können sie vollständig laden und in n8n weiterverarbeiten.

Serverfehler statt Ergebnis

Diese Aufrufe brechen mit HTTP 500 ab, meist mit einer durchgereichten SQL-Fehlermeldung — ein klares Zeichen, dass der Fehler in der API selbst liegt und nicht in den übergebenen Werten:

Ressource	Auslöser	Meldung der API
Artikel	Suchen in	Falsche Syntax in der Nähe von "Preisverweis"
Ressourcen	Suchen in auf /OperatingResources	Mehrdeutiger Spaltenname "Id"
Inventur	Suchen in auf /Inventories/{nummer}/Warehouses	Ungültiger Spaltenname "LagerBezeichnung"
Produktion	Sortieren nach und Filter auf /ProductionOrders/{id}/ProductionSteps/{schritt}/Articles	Mehrdeutiger Spaltenname "Artikelnummer"
Journal	Filter auf /Journals	SqlException … Fehler beim Konvertieren einer Zeichenfolge in "uniqueidentifier"
Auswertungen	/Analysis/Total, /Analysis/TopArticles, /Analysis/TopCustomers, /Analysis/TopSuppliers, /Analysis/TopEmployees ohne Auswertungsparameter	Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt

Bei den Auswertungen fehlten im Prüflauf die Auswertungsparameter. Erwartbar wäre dann ein Hinweis auf das fehlende Pflichtfeld (HTTP 400) — stattdessen kommt ein interner Serverfehler.

Filterbare Eigenschaften weichen von den gelieferten ab

Bei Ressourcen (/AlternativeResources) liefert die API das Feld AlternativeResourceId aus, weist es im Filter aber ab:

Die Eigenschaft AlternativeResourceId konnte nicht zugeordnet werden. – 74-013

Filterbar ist also nicht zwangsläufig, was in der Antwort steht. Welche Eigenschaften ein Endpunkt zum Filtern akzeptiert, gibt die API nicht bekannt — hier hilft nur Ausprobieren oder die Rückfrage beim SelectLine-Partner.

Sortierung: auffällig, aber nicht abschließend geklärt

Bei drei Endpunkten ändert Sortieren nach die Reihenfolge, das Ergebnis ist aber nicht durchgehend sortiert: /Articles (nach Number), /Accounting/TaxCodes (nach TaxCodeNumber) und /Journals (nach Identifier).

Nicht jede abweichende Reihenfolge ist ein Fehler

Das kann auch an unterschiedlicher Sortierlogik liegen: die Datenbank sortiert nach ihrer Kollation, die Prüfung nach deutscher Zeichenfolge. Bei Zahlen in Textfeldern (10 vor 9) ist das normal und kein Fehler. Vor einer Meldung an SelectLine bitte am konkreten Fall prüfen, ob die Reihenfolge fachlich falsch ist.

Nicht auf dieser Liste: Konfiguration

Zwei Dinge, die im Prüflauf ebenfalls fehlschlugen, sind keine API-Fehler, sondern Einstellungssache:

Buchhaltung braucht ein aktives Jahr. Alle /Accounting/…-Abfragen antworteten mit HTTP 424, „To access this route you have to select an active year first”. Abhilfe: in den Anmeldedaten das Feld Standard-Jahr (Datenbankname) füllen. Siehe Mandanten und Sitzungen.

Fachliche Vorbedingungen. Manche Endpunkte gelten nur für bestimmte Daten — etwa /Warehouses/{lager}/StoragePlaces/Stocks: „Das Lager muss vom Typ 2 oder 3 (Flächen- oder Regallager) sein.“ Die API verhält sich hier korrekt.

Was Sie stattdessen tun können

1. Wo Suchen nach nicht greift, Filter versuchen — und umgekehrt. Die beiden werden in der API getrennt umgesetzt; bei den meisten betroffenen Endpunkten funktioniert der Filter.
2. Ressourcen-eigene Felder nutzen. Die zusätzlichen Felder einer Ressource (Artikelgruppennummer, Belegstatus, Nur Favoriten …) sind eigene Parameter und von den Einschränkungen hier meist nicht betroffen.
3. Nachgelagert in n8n filtern. Liste laden und mit einer Filter- oder IF-Node einschränken. Bei den betroffenen Endpunkten (Lager, Inventur, Produktion, Mandanten) sind die Mengen überschaubar.
4. Bei Serverfehlern den auslösenden Parameter weglassen. Ohne Suchen in liefert dieselbe Abfrage bei Artikeln ein Ergebnis; die Einschränkung übernimmt dann Suchen nach oder der Filter.
5. Nicht mit Einträge = 0 kompensieren. Wenn der Filter serverseitig verpufft, lädt das den gesamten Bestand. Lieber begrenzt laden und in n8n aussortieren.

Fall an uns melden

Melden Sie den Fall bitte bei cotec it-systeme GmbH, auch wenn die Ursache in der SelectLine-API liegt. Sie müssen die Zuordnung nicht selbst treffen — genau das übernehmen wir:

1. Wir prüfen den Fall nach und grenzen ihn ab: Bedienung, Konfiguration (Mandant, Jahr, Rechte), Node oder API.
2. Liegt es an der Node oder an der Einrichtung, beheben wir es direkt.
3. Bestätigt sich ein API-Fehler, geben wir ihn mit den Nachweisen — den exakten Aufrufen, Trefferzahlen und Fehlermeldungen aus unserem Prüfbericht — an SelectLine weiter und informieren Sie über den Stand.

So landet die Meldung beim Hersteller in einer Form, die dort reproduzierbar ist, und Sie müssen keine Schnittstellendetails aufarbeiten.

Hilfreich für die Meldung, soweit Sie es zur Hand haben:

• Ressource und Operation, bei der es auftritt, und welche Listenoption wirkungslos bleibt,
• die Beobachtung: gleiche Abfrage mit und ohne den Parameter, jeweils die Anzahl der Datensätze,
• bei Fehlermeldungen die vollständige Meldung inklusive Fehlercode (z. B. 74-013, 20-000),
• SelectLine-Version, Mandant und die Version der Node.

Kontakt: support@cotec-it-systeme.de oder Ihr gewohnter Ansprechpartner bei cotec it-systeme GmbH.

Stand

Erhoben am 29.09.2026. Mit einer neuen SelectLine-Version kann sich das Verhalten ändern — im Zweifel den Einzelfall nachprüfen: Abfrage einmal mit und einmal ohne den Parameter ausführen und die Anzahl der Datensätze vergleichen.