Einkaufsanalyse nach Artikel im Web Client: Was SAP (noch) nicht mitliefert, und wie man es sich selbst baut
Stand: Juli 2026 | SAP Business One 10.0, Web Client SP2605
Die Ausgangsfrage
Eine scheinbar triviale Anforderung: „Zeige mir alle Eingangsrechnungen, in denen Artikel X eingekauft wurde.“ Im Desktop-Client ist das seit Jahren ein Ein-Klick-Vorgang. Einkaufsanalyse öffnen, nach Artikel und Zeitraum filtern, Doppelklick auf die Ergebniszeile, fertig. SAP springt direkt zu den zugrunde liegenden Belegen.
Im Web Client sucht man diese Funktion vergebens. Die Recherche dazu zeigt exemplarisch, wo der Web Client aktuell steht: Leistungsfähig unter der Haube, aber an entscheidenden Stellen noch nicht zu Ende gedacht!
Kritik: Die Lücke ist real
Der Web Client bietet für den Verkauf eine eigene Verkaufsanalyse-Berichtssicht inklusive nativer Datenaufschlüsselung (Drilldown auf Belegebene), also genau die Funktion, die man sich für den Einkauf wünschen würde. Eine äquivalente Einkaufsanalyse-Berichtssicht existiert dort schlicht nicht. Wer im Einkauf nach Artikel filtern will, landet bei den Standard-Listenansichten der Eingangsrechnungen. Die sind aber beleg- (kopf-)basiert und bieten keine Filterung auf Positionsebene.
Der naheliegende Workaround, Benutzerdefinierte Abfragen (UDQ), funktioniert zwar inhaltlich, aber nicht dort, wo man ihn zuerst vermutet. Die Funktion „Verknüpfte Listenansichten“, mit der sich normalerweise Objekte klickbar miteinander verbinden lassen, akzeptiert UDQs weder als Quelle noch als Ziel. Bis man das durch Ausprobieren zweifelsfrei ausgeschlossen hat, kostet das unnötig Zeit. Ein Hinweis in der Dokumentation dazu wäre wünschenswert.
Lob: Wo es dann doch elegant wird
Der eigentliche Weg liegt eine Ebene tiefer, direkt in der UDQ selbst, und der ist tatsächlich gut gemacht.
Echte Laufzeitparameter. UDQs unterstützen benannte Parameter (:parametername) mit Typ und optionalem Standardwert. Kein reines Static-SQL-Konstrukt, sondern eine Abfrage, die sich wie ein kleines Formular verhält.
Spaltenweise Objektverknüpfung. Im Reiter „Spalten“ lässt sich jede Spalte gezielt mit einer Systemtabelle verknüpfen (DocEntry zu OPCH, ItemCode zu OITM etc.). Genau das erzeugt den gesuchten Effekt: Sobald die Ergebnisliste über „In Listenansicht öffnen“ dargestellt wird, sind Belegnummer, Geschäftspartner und Artikelnummer automatisch anklickbar und führen direkt in die jeweilige Detailsicht.
Sofort nutzbare Listenansicht. Die UDQ-Ergebnisliste kommt automatisch mit Filterleiste, Gruppierung, Tabellen-/Diagrammansicht und Excel-Export. Alles Bordmittel, kein Zusatzaufwand.
Beispielhafte Abfrage (HANA-Syntax) für „alle Eingangsrechnungspositionen zu einem Artikel“:
SELECT T0."DocEntry", T0."DocNum", T0."DocDate", T0."CardName", T1."ItemCode", T1."Dscription", T1."Quantity", T1."LineTotal" FROM OPCH T0 INNER JOIN PCH1 T1 ON T0."DocEntry" = T1."DocEntry" WHERE T0."CANCELED" = 'N'
Ohne Artikel-Filter im WHERE liefert das eine vollständige Übersicht aller Einkaufspositionen, die sich anschließend direkt in der Listenansicht nach Artikelnummer filtern und gruppieren lässt. Für den Einzelfall reicht ein Parameter à la :myItemCode, für die Massenauswertung lässt man ihn einfach weg.
Stolperfallen beim Spalten-Mapping
Zwei Dinge, die beim Nachbauen leicht schiefgehen und nirgends dokumentiert sind.
„Verknüpfung mit“ gehört nur auf das Schlüsselfeld. Es ist verlockend, bei allen Spalten aus derselben Quelltabelle (DocEntry, DocNum, DocDate, CardName) pauschal „Verknüpfung mit: OPCH“ zu setzen, schließlich gehören sie ja alle zum selben Beleg. Das führt aber dazu, dass die Listenansicht durcheinanderkommt, welcher Wert der eigentliche Schlüssel ist und welcher nur Anzeigefeld. In unserem Testfall zeigte „Interne Nummer“ plötzlich den DocNum-Wert statt des echten DocEntry. Richtig ist: nur das eindeutige Schlüsselfeld (DocEntry) mit dem Objekt verknüpfen, alle anderen Spalten bleiben ohne Objektverknüpfung.
Verknüpfte Spalten zeigen die Objekt-Standardanzeige, nicht den Rohwert. Sobald eine Spalte korrekt mit einem Objekt verknüpft ist, ersetzt der Web Client den ursprünglichen SQL-Wert durch die Standard-Darstellung dieses Objekts. Bei Belegen ist das die Belegnummer (DocNum), nicht der interne Schlüssel (DocEntry). Der Link selbst funktioniert trotzdem korrekt, intern wird weiterhin der echte DocEntry für die Navigation verwendet, aber wer bewusst den Rohwert anzeigen wollte, wird von der Anzeige überrascht. Rein kosmetisch, aber gut zu wissen, bevor man auf die Suche nach einem vermeintlichen Bug geht.
Fazit
Der Web Client zwingt an dieser Stelle zu einem Umweg, den es im Desktop-Client nicht braucht. Das ist ein echter Funktionsrückstand, den SAP schließen sollte, zumal die Verkaufsseite zeigt, dass man es besser kann. Gleichzeitig ist bemerkenswert, mit wie wenig Aufwand sich diese Lücke selbst schließen lässt: eine SQL-Abfrage, ein paar Klicks in den Spalten-Metadaten, fertig ist eine wiederverwendbare, klickbare Analyse-Kachel. Ganz ohne Programmierung, ganz ohne Crystal Reports, ganz ohne Entwickler-Zugriff auf die Datenbank. Das ist state of the art für Self-Service-Analytics im SMB-Umfeld.
Offen für einen Folgebeitrag: Ob sich mehrere Belegarten (Eingangsrechnung, Eingangsgutschrift) per UNION ALL in einer Query kombinieren lassen, ohne die Objektverknüpfung pro Zeile zu verlieren. Dazu bald mehr, sobald der Praxistest steht.