So verarbeiten Sie 50 Bau-Bestellungen im Stapel
zu einem Auftragskostenblatt

Warum Bau-PO-Stapel alle auf einmal eintreffen – und warum das ein strukturelles Problem ist, kein Planungsproblem

In den meisten Branchen entscheiden Sie, wann Sie einen Stapel verarbeiten. Sie lassen Rechnungen eine Woche lang auflaufen und verarbeiten sie dann gemeinsam. Im Bauwesen wird der Zeitpunkt des Stapels für Sie bestimmt – durch den monatlichen Ziehungszyklus und die Materialvorlaufzeiten.

Gemäß AIA A201 §9.3 reicht der Auftragnehmer jeden Monat einen konsolidierten Zahlungsantrag beim Eigentümer ein. Aber bevor dieser Antrag den Eigentümer erreicht, muss der GU alle Materialkosten abgleichen, die über alle aktiven Projekte hinweg bestellt, geliefert oder eingebaut wurden. Das bedeutet, dass jede Material-PO – vom Holzhändler, vom Betonwerk, vom Stahlbauer, vom MEP-Händler – im Auftragskostensystem sein muss, mit dem richtigen Kostencode und dem richtigen Projekt versehen, bevor das Ziehungspaket rausgeht.

Gleichzeitig sind Materialbestellungen nicht gleichmäßig über den Monat verteilt. Ein Rahmenpaket für Projekt A wird in Woche 1 bestellt und die PO trifft in Woche 2 ein. Die Dachmaterialien für Projekt B werden in Woche 3 bestellt und die PO erscheint in Woche 4. Aber alle müssen vor dem Monatsabschluss abgeglichen werden – das ist dieselbe Woche. Für einen GU, der fünf bis acht Projekte betreibt, ist das Zeitfenster brutal: 50 bis 150 Material-POs treffen innerhalb desselben 10-Tage-Zeitraums jeden Monat ein.

Das unterscheidet sich von der Rechnungsstapelung der Subunternehmer, wo der Schmerz in 30 verschiedenen Formaten liegt, die auf dieselbe Frist zulaufen. Hier kommt die zusätzliche Ebene hinzu: Kostenzuordnung: Jede Position auf jeder Material-PO muss einer CSI-MasterFormat-Division, einem Abschnitt und einer Kostenart zugeordnet werden, bevor sie in das Auftragskosten-Hauptbuch einfließen kann. Diese Zuordnung ist eine kognitive Aufgabe, keine Dateneingabe – und genau das macht die Verarbeitung von Bau-POs um eine Größenordnung schwieriger als die allgemeine Beschaffung.

Was der Lieferant sendet vs. was Ihr Auftragskostensystem verlangt

Die Kluft zwischen der PO eines Lieferanten und Ihrem Auftragskostensystem ist größer, als die meisten annehmen – und sie beginnt bereits bei den Feldern selbst.

Eine typische PO eines Materiallieferanten enthält: Lieferantenname, PO-Datum, PO-Nummer, Artikelcode (dessen SKU), Artikelbeschreibung („2×6 #2 SPF 16'“), bestellte Menge, Einzelpreis, Positionssumme und eine Gesamtsumme. Manchmal, wenn Sie Glück haben, ein Projektname im Feld „Referenz“. Fast nie Ihre interne Auftragsnummer, Ihr Kostencode oder Ihre Kostenart – denn das ERP des Lieferanten spricht kein CSI MasterFormat und kennt Ihre Buchhaltungsstruktur nicht.

Ihr Auftragskostensystem – ob Sage 100 Contractor, Sage Intacct, Viewpoint Vista, Foundation oder QuickBooks mit einem Bau-Add-on – benötigt: Auftragsnummer, Kostencode (z. B. 06 11 00 für Holzrahmenbau), Kostenart (Material, Arbeit, Ausrüstung, Subunternehmer, Sonstiges), Phase oder Unterprojekt, Lieferantenname, PO-Nummer, Datum, Artikelbeschreibung, Menge, Einzelpreis, Positionssumme und ob diese Kosten gebunden oder tatsächlich sind. Das sind mindestens fünf Felder, die die PO des Lieferanten nicht enthält – und genau diese Felder entscheiden, ob Ihre Auftragskostenberichte korrekt oder Fiktion sind.

Diese Lücke zu schließen ist die Aufgabe des Projektbuchhalters, Position für Position: Artikelbeschreibung lesen → feststellen, zu welcher CSI-Division sie gehört → den 6-stelligen Kostencode nachschlagen oder aus dem Gedächtnis abrufen → die Auftragsnummer zuweisen → die Kostenart eingeben → schließlich Menge und Preis eintippen, die bereits auf der Seite standen. Bei einer PO mit 12 Positionen sind das 12 Durchläufe dieser Denkschleife. Bei 50 POs mit durchschnittlich 8 Positionen sind es 400 Durchläufe – in einer Woche, in der die Ziehungsfrist bereits näher rückt.

Das Kostencode-Problem: Wenn „2×6 druckimprägniert“ nicht dasselbe ist wie 06 11 00

CSI MasterFormat organisiert Bauarbeiten in 50 Gewerke, die jeweils in Abschnitte und Unterabschnitte mit 6-stelligen Codes unterteilt sind. Gewerk 03 ist Beton. Gewerk 04 ist Mauerwerk. Gewerk 06 ist Holz, Kunststoff und Verbundstoffe. Innerhalb von Gewerk 06 ist 06 11 00 Holzbau, während 06 16 00 Beplankung ist. Der Unterschied zwischen 06 11 00 und 06 16 00 ist nicht trivial – es ist der Unterschied zwischen Tragwerk und Gebäudehülle, und ein Projektleiter, der eine Kostenüberschreitungswarnung für 06 11 00 sieht, muss wissen, dass die Zahl real ist.

Das Problem: Die PO Ihres Holzhändlers sagt nicht „06 11 00“. Sie sagt „2×6 #2 SPF 16′“ mit deren interner SKU. Die PO des Bewehrungsherstellers listet „#4 Grade 60 Bewehrungsstahl – 20′-Längen“. Die PO des Trockenbau-Lieferanten sagt „5/8″ Type X Gipskartonplatte“. Keine davon enthält einen CSI-Code. Jemand muss jede Position lesen, sie gedanklich klassifizieren und den richtigen Code zuweisen. Und das dann für die nächsten 399 Positionen wiederholen.

Hier bricht der manuelle Prozess zusammen – nicht weil jemand schlecht in seinem Job ist, sondern weil Kontextwechsel teuer sind. Sie wechseln von der Klassifizierung einer Rahmenholz-Position (06 11 00) zu einem Betonanker (03 16 00) zu einem HLK-Kanalabhänger (23 31 00) innerhalb von drei Positionen. Bei Position 200 setzt Ermüdung ein, und eine Trockenbauschraube – die in 09 29 00 (Gipskartonplatten) gehört – wird als 06 11 00 codiert, weil Ihr Gehirn vom vorherigen PO noch im „Holz“-Modus ist. Der Fehler wird erst zum Monatsende sichtbar, wenn Gewerk 06 Kosten zeigt, die zu keiner Rahmenbau-Aktivität passen, und jemand einen Nachmittag damit verbringt, ihn zurückzuverfolgen.

Bau-Softwareplattformen sind sich dieses Problems bewusst – deshalb erzwingen Procore, CMiC und Viewpoint Vista die Kostencode-Auswahl bei der Erfassung der Verpflichtung. Aber diese Durchsetzungsmechanismen funktionieren nur, wenn die Daten bereits im System sind. Sie lösen nicht das Problem, sie aus einer PDF des Lieferanten in das System zu bekommen.

Für einen tieferen Einblick in die Zuordnung von CSI-MasterFormat-Codes bei der Einzel-PO-Extraktion – einschließlich der Einrichtung von Kostencode-Spalten und mehrstufiger Projektphasen-Hierarchien – siehe unseren Leitfaden zur Kostencode-Extraktion aus Bau-Bestellungen.

Der Batch-Workflow: Einmal definieren, von jedem Lieferanten extrahieren

Die operative Alternative besteht darin, den Workflow umzukehren: Definieren Sie Ihr Ausgabeschema – die genauen Spalten, die Ihr Auftragskostensystem erwartet – einmal, und führen Sie dann jede Lieferanten-PO durch dieselbe Extraktionspipeline. Statt eine PO nach der anderen zu verarbeiten (extrahieren, herunterladen, in die Mastertabelle kopieren, wiederholen), verarbeiten Sie 50 POs als eine Einheit und erhalten eine einheitliche Ausgabe.

Sie beginnen mit der Definition Ihrer Spaltenüberschriften – dieselben Überschriften, die Ihr Auftragskostensystem oder Ihre ERP-Importvorlage erwartet:

Dann laden Sie alle 50 POs hoch – das PDF vom Holzhändler, den Scan vom Trockenbau-Großhändler, den Systemausdruck vom Bewehrungshersteller, das QuickBooks-generierte Bestellformular vom MEP-Lieferanten – als einen einzigen Stapel. Dies ist eine Spaltennamen-Extraktion: Statt dem Tool zu sagen, wo jedes Feld auf jedem Dokument sitzt (was 50 Vorlagen erfordern würde), sagen Sie ihm, was jedes Feld bedeutet. Die KI findet „PO Number“ im Format des Holzhändlers, indem sie versteht, was eine PO-Nummer ist – nicht, wo sie in der Ecke des jeweiligen Layouts sitzt. Sie findet „Line Total“, egal ob der Lieferant es in der äußersten rechten Spalte einer Tabelle platziert oder direkt unter der Positionsbeschreibung ohne Spaltenüberschrift.

Der operative Unterschied, der am meisten zählt: Sie laden eine Datei herunter, nicht 50. Eine Tabelle mit jeder Position aus jeder PO, alle Spalten identisch, alle Zeilen bereit zum Sortieren nach Auftragsnummer oder Filtern nach Kostencode. Es gibt keinen Konsolidierungsschritt – kein Öffnen von 50 einzelnen Exporten, kein Kopieren von Zeilen in eine Mastertabelle, kein Hoffen, dass nichts verrutscht. Die Zusammenführung erfolgt zum Zeitpunkt der Extraktion, nicht danach.

Der Skalierungsvorteil zeigt sich, wenn Ihre Lieferantenanzahl wächst. Das Hinzufügen eines 41. Lieferanten mit einem weiteren PO-Format kostet Sie keine zusätzliche Einrichtungszeit – es gibt keine Vorlage zu erstellen, keine Begrenzungsrahmen zu zeichnen, keine lieferantenspezifische Konfiguration. Die Spaltendefinitionen sind formatunabhängig. Der PO des 41. Lieferanten fließt in dieselbe Pipeline wie die ersten 40, und die Ausgabe ist dieselbe einheitliche Tabelle mit denselben Spalten. Dies ist der Unterschied zwischen einem Prozess, der mit zunehmender Skalierung schwieriger wird, und einem, der konstant bleibt.

Wenn der PO Ihre interne Auftragsnummer nicht enthält

Hier ist ein bauspezifisches Problem, das generische PO-Extraktionsanleitungen nie ansprechen: Die meisten Materiallieferanten haben Ihre interne Auftragsnummer nicht in ihrem System. Sie haben ihre Bestellnummer. Sie haben möglicherweise einen Projektnamen, wenn Sie sie gebeten haben, ihn in das Referenzfeld einzutragen. Aber „Auftrag 24-005“ – der Schlüssel, der jede Kostenposition in Ihrem Buchhaltungssystem dem richtigen Projekt zuordnet – fehlt im Dokument selbst.

In einem manuellen Arbeitsablauf bedeutet dies, dass der Projektbuchhalter den Lieferantennamen ansehen, ihn gedanklich dem richtigen Projekt zuordnen („Builders FirstSource = Auftrag 24-005, Site Concrete Supply = Auftrag 24-003“) und die Auftragsnummer manuell für jede Position auf diesem PO eingeben muss. Bei 50 POs über 8 Projekte sind das 50 manuelle Auftragsnummern-Zuweisungen, jede eine Gelegenheit, die Materialien von Site Concrete dem falschen Projekt zuzuordnen.

Hier verändern abgeleitete Spalten die Gleichung. Eine abgeleitete Spalte extrahiert nicht nur, was auf der Seite steht – sie wendet eine von Ihnen definierte Regel an, um einen Wert zu bestimmen, der nirgendwo auf dem Dokument gedruckt ist. Für Auftragsnummern definieren Sie eine Spalte namens „Auftrag #“ mit Inferenzregeln wie:

Wenn die KI einen PO von Builders FirstSource verarbeitet, liest sie den Lieferantennamen auf dem Dokument, gleicht ihn mit Ihrer Regel ab und füllt die Spalte „Auftrag #“ mit „24-005“ – automatisch, über jede Position auf diesem PO. Ein PO von Site Concrete Supply erhält „24-003“. Wenn ein neuer Lieferant erscheint, dessen Name nicht in Ihrer Regelliste steht, bleibt die Zelle leer – kein falsches Raten, kein stiller Fehler – und Sie bemerken es während des Prüfschritts.

Dasselbe Inferenzmuster funktioniert für Kostencodes. Wenn jede Bestellung von Gerdau Rebar an 03 21 00 (Bewehrungsstahl) geht, fügen Sie diese Regel hinzu. Wenn Builders FirstSource sowohl Rahmenholz (06 11 00) als auch Beplankung (06 16 00) liefert, erfolgt die Inferenz pro Positionsbeschreibung, nicht pro Lieferant – die KI liest „2×6 #2 SPF“ und ordnet 06 11 00 zu, liest „7/16″ OSB“ und ordnet 06 16 00 zu. Sie definieren die Zuordnung einmal; sie läuft automatisch über jeden PO im Stapel.

Der Nettoeffekt: Von diesen 400 manuellen Klassifizierungsentscheidungen über 50 POs hinweg wird ein großer Teil — typischerweise 70 % oder mehr bei einem Auftragnehmer mit stabilen Lieferantenbeziehungen — durch Inferenzregeln abgedeckt. Was für den Prüfschritt übrig bleibt, sind die 30 %: neue Lieferanten, ungewöhnliche Materialarten oder mehrdeutige Beschreibungen, die eine menschliche Entscheidung erfordern. Das sind 120 Entscheidungen statt 400 — und die verbleibenden 120 haben eine leere Zelle, die sie für Sie markiert, statt eines falschen Codes, der still im Datensatz steckt.

Vom Stapel-Output zur Auftragskosten-Abstimmung

Die heruntergeladene Tabelle ist nicht die Ziellinie. Sie ist die Grundlage für die drei Prüfungen, die aus extrahierten Daten einen zuverlässigen Auftragskostenbericht machen.

1. Nach Auftrag und Kostencode sortieren und Zwischensummen bilden. Mit ausgefüllten Spalten für Auftragsnummer und Kostencode gruppiert eine einzige Sortierung jede PO-Position nach Projekt und dann nach CSI-Abteilung innerhalb jedes Projekts. Bilden Sie Zwischensummen der Positionssummen-Spalte nach Auftragsnummer, um die gebundenen Materialkosten pro Projekt zu erhalten. Bilden Sie Zwischensummen nach Kostencode, um genau zu sehen, wie viel für Abteilung 03 (Beton) im Vergleich zu Abteilung 06 (Holz) im Vergleich zu Abteilung 09 (Ausbau) gebunden ist. Was früher das Summieren über 50 separate PO-Dateien erforderte, ist jetzt eine einzige Pivot-Tabelle auf einem Blatt.

2. Gebundene Kosten mit dem Projektbudget vergleichen. Jeder Auftrag hat ein Kostenbudget, das nach Kostencode aufgeschlüsselt ist — entweder in Ihrem ERP (Sage, Viewpoint, Procore) oder in einer vom Projektleiter gepflegten Tabelle. Mit Ihrem Stapel-Ergebnis, das nach Kostencode summiert ist, zeigt ein VLOOKUP gegen das Budget sofort Abweichungen: Division 06 ist 12 % über dem gebundenen Budget, weil die Holzpreise gestiegen sind. Division 03 ist 5 % darunter, weil der Betonguss kleiner war als geschätzt. Das sind die Gespräche, die Sie vor dem Versand des Ziehungspakets führen möchten, nicht erst nach der Unterzeichnung der Sicherheitsleistungen.

3. Gebundene Kosten von tatsächlichen Kosten trennen. Eine PO stellt eine gebundene Kosten dar — Geld, das Sie verpflichtet, aber nicht unbedingt ausgegeben haben. Die Rechnung, die bei Materiallieferung eintrifft, stellt tatsächliche Kosten dar. Diese Unterscheidung ist grundlegend für die Bauabrechnung: Gebundene Kosten beeinflussen Ihre Budget-zu-IST-Prognose; tatsächliche Kosten beeinflussen Ihren Cashflow. Das Stapel-Ergebnis, mit einer Spalte, die verfolgt, ob jede Position „gebunden“ oder „in Rechnung gestellt“ ist, liefert beide Zahlen auf demselben Blatt. Sortieren Sie nach Status, um sie zu trennen; bilden Sie Zwischensummen für beide, um die Lücke zwischen gebunden und tatsächlich pro Auftrag zu sehen.

Für Auftragnehmer, deren PO-Volumen über das hinausgewachsen ist, was selbst ein gut gestalteter Stapel-Workflow in der verfügbaren Zeit bewältigen kann, deckt das Skalierungsframework in unserem Leitfaden zur Skalierung der Dokumentenverarbeitung ohne zusätzliches Personal die organisatorische Seite ab — vom Prozessdesign bis zur Teamstruktur bei verschiedenen Volumenschwellen.

Wenn eine Extraktion schiefgeht: Teilweises erneutes Verarbeiten statt komplettem Neustart

In einem Stapel von 50 POs stimmt bei mindestens zwei oder drei etwas nicht. Ein verschmierter Scan, bei dem die KI $4.200 als $4.800 liest. Eine Lieferanten-PO mit einem zweispaltigen Layout, das die KI als eine Tabelle interpretiert hat. Ein handschriftlicher Lieferschein, der in einen Stapel gedruckter POs geraten ist und dessen Handschrift teilweise unleserlich ist. Die Frage ist nicht, ob Fehler auftreten – sondern ob deren Behebung Sie zwingt, den gesamten Stapel erneut zu verarbeiten.

Die Stapelausgabe ist eine einzige Tabelle, in der jede Zeile zu einer Position aus einer PO gehört. Wenn in Zeile 37 (dem fünften Posten der Holz-PO von Builders FirstSource) eine falsche Menge steht, fassen Sie die Zeilen 1–36 oder 38–400 nicht an. Sie verarbeiten nur diese eine PO erneut, kopieren die korrigierte Zeile über die fehlerhafte und machen weiter. Die Tabellenstruktur bleibt intakt. Es gibt keine Kettenreaktion – kein „PO #17 neu extrahieren, dann alle Dateien neu zusammenführen, dann die Pivot-Tabellen neu aufbauen.“ Der Fehler bleibt auf seine Zeile beschränkt, und die Korrektur bleibt auf dieselbe Zeile beschränkt.

Das ist der Unterschied zwischen einem Stapelprozess, dem Sie vertrauen, um ihn am Abend vor der Ziehungsfrist auszuführen, und einem, den Sie nach dem ersten Mal aufgeben, wenn er mehr Arbeit verursacht, als er gespart hat. Der Stapelworkflow muss nicht perfekt sein. Er muss eingrenzbar sein – sodass eine fehlerhafte Extraktion nicht in zwei Stunden Dateirekonstruktion ausartet. Bei einer Fehlerquote von 4–6 % (typisch für Baudokumente mit gemischten Formaten und unterschiedlicher Scanqualität) beträgt die Korrekturzeit bei teilweiser Neuverarbeitung 5 Minuten – 3 fehlerhafte POs einzeln neu extrahiert, korrigierte Zeilen eingefügt – gegenüber 45 Minuten für den kompletten Stapel. Das ist die Kennzahl, die darüber entscheidet, ob der Workflow dem Monatsenddruck standhält.

Häufig gestellte Fragen

Kann das POs verarbeiten, die Materialarten mischen – zum Beispiel ein einzelner Lieferant, der sowohl Schnittholz als auch Befestigungsmittel in derselben Bestellung liefert?

Ja. Jede Position auf der PO erhält eine eigene Zeile in der Ausgabe, und jede Zeile erhält einen eigenen Kostencode basierend auf der Artikelbeschreibung. Eine PO von einem Baustoffhändler mit 2×6-Rahmenholz (06 11 00), OSB-Platten (06 16 00) und Balkenschuhen (06 05 23) erzeugt drei Zeilen mit drei verschiedenen Kostencodes – alle aus demselben Dokument, alle in derselben Stapelausgabe. Die Inferenzregeln übernehmen die Klassifizierung pro Artikel; Sie müssen die PO vor der Verarbeitung nicht aufteilen.

Was ist, wenn ich POs als E-Mail-Text oder als Handyfotos handschriftlicher Bestellungen erhalte?

Die Extraktions-Engine verarbeitet beides im selben Stapel wie PDFs und Scans. Bei E-Mail-POs machen Sie einen Screenshot und laden ihn hoch. Bei Handyfotos handschriftlicher Bestellungen liest die KI die Handschrift genauso wie gedruckten Text – die Lesbarkeit ist der Hauptfaktor, der die Genauigkeit beeinflusst. Eine klare handschriftliche Notiz auf dem Briefkopf eines Lieferanten wird mit etwa derselben Genauigkeit extrahiert wie eine gedruckte PO. Ein verschmierter Durchschlag, der bei schlechtem Licht fotografiert wurde, hat eine geringere Genauigkeit und sollte für den Prüfschritt markiert werden.

Muss ich meine Inferenzregeln jedes Mal aktualisieren, wenn ich einen neuen Lieferanten hinzufüge oder ein neues Projekt starte?

Für einen neuen Lieferanten: Ja, Sie fügen eine Regel hinzu – „Neuer Lieferantenname → Auftragsnummer“ – zu Ihrer Inferenzspalte vor der Verarbeitung. Das ist eine einzelne Textbearbeitung, kein Vorlagen-Neuaufbau. Für ein neues Projekt: Sie fügen Regeln hinzu, die die diesem Projekt zugewiesenen Lieferanten der neuen Auftragsnummer zuordnen. Wenn Sie Site Concrete Supply von Auftrag 24-003 auf Auftrag 24-008 verschieben, aktualisieren Sie eine Zeile in Ihrer Inferenzregel. Die Spaltennamen-Extraktionsebene ändert sich nicht – dieselben Spalten „Lieferantenname / PO-Nummer / Artikelbeschreibung / Menge / Einzelpreis“ funktionieren unabhängig davon, welche Projekte aktiv sind.

Wie verarbeitet die Stapelverarbeitung Einbehalte bei Material-Bestellungen?

Die meisten Material-POs enthalten keine Einbehalte – Einbehalte gelten typischerweise für Subunternehmerverträge, nicht für Materialkäufe. Für die Fälle, in denen dies doch zutrifft (Sonderanfertigungen mit Teilzahlungen oder Lieferantenverträge mit Einbehaltsklausel), können Sie eine berechnete Spalte hinzufügen – eine Spalte, die während der Extraktion einen Wert berechnet, statt ihn nur von der Seite abzulesen. Definieren Sie „Netto fällig“ mit der Logik Positionssumme × (1 − Einbehaltsprozentsatz) und die KI berechnet ihn pro Position, pro PO. Der Einbehaltssatz kann aus dem PO übernommen werden, falls dort aufgeführt, oder als fester Parameter in der Spaltendefinition angegeben werden. Für eine detailliertere Behandlung berechneter Spalten über Dokumenttypen hinweg, siehe unsere Einführung in berechnete Spalten bei der Dokumentextraktion.

Ersetzt dies mein Bau-ERP?

Nein. Dies löst die Datenerfassungsebene – Material-PO-Daten aus Lieferanten-PDFs in ein strukturiertes, kostencode-zugeordnetes Format zu bringen. Es ersetzt nicht die Genehmigungsrouting Ihres Buchhaltungssystems, den Dreifachabgleich (PO-zu-Eingang-zu-Rechnung), die Zahlungsabwicklung, die Verwaltung von Pfandverzichterklärungen oder die WIP-Berichterstattung. Für einen Auftragnehmer mit QuickBooks + Tabellenkalkulationen speist die Stapelausgabe direkt in Ihre Auftragskosten-Arbeitsmappe. Für einen Auftragnehmer mit Sage 100, Sage Intacct oder Viewpoint Vista ersetzt es den Schritt zwischen „Lieferanten-PO erhalten“ und „Daten ins ERP importiert“ – der in vielen Firmen immer noch ein Mensch ist, der ein PDF liest und Zahlen in einen ERP-Bildschirm tippt. Für die Einzel-PO-Verarbeitung – das Extrahieren von Feldern aus einem einzelnen Bau-PO statt einer vollständigen Stapelverarbeitung – deckt unser Leitfaden zur Einzel-PO-Extraktion den Arbeitsablauf im Detail ab.

Kann ich POs aus mehreren Projekten in einem Stapel verarbeiten?

Ja – und das ist der operative Vorteil, wenn Sie Auftragsnummer als Spalte aufnehmen. Laden Sie POs aus allen acht aktiven Projekten in einem Stapel hoch. Die Inferenzregeln weisen die POs jedes Lieferanten während der Extraktion der richtigen Auftragsnummer zu. Nach dem Download sortieren Sie nach Auftragsnummer, um alle Positionen nach Projekt zu gruppieren. Eine Zwischensumme der Positionssumme pro Auftragsnummer ergibt in Sekunden die gebundenen Materialkosten pro Projekt. Die Alternative – acht separate Stapel, einer pro Projekt, und dann Konsolidierung – ist genau die Art von Fragmentierung, die der Stapelarbeitsablauf eliminiert.