Purchase Order Benutzerhandbuch

Das Purchase-Order-Modul unterstützt einen kontrollierten Einkaufsprozess von der ersten Einkaufsanforderung über den Offertenvergleich, die Freigabe, die Bestellung, die Lieferbestätigung und die Übergabe der Rechnung an Finance.

Purchase Order ist ein eigenständiges centraQuest-Modul mit eigenem Purchase-Order-Workflow. Eine Purchase Order wird als strukturierter Geschäftsfall gespeichert: mit Antragsteller, Freigebern, Lieferantenofferten, Positionen, Anhängen, Budgetinformationen, Verlauf und späteren Rechnungsreferenzen.

Purchase Order unterstützt mehrere Prozessvarianten. Der wichtigste Unterschied ist, ob eine Lieferbestätigung erforderlich ist und ob die Rechnung als normale Rechnung, Vorauszahlung oder Teilzahlungsprozess verarbeitet wird.

Zweck

Purchase Order wird verwendet, wenn ein Einkauf geprüft und freigegeben werden soll, bevor die Lieferantenrechnung eintrifft. Das Modul hilft bei diesen Fragen:

• Was wird gekauft?
• Wer hat den Einkauf beantragt?
• Welche Abteilung oder Kostenstelle ist zuständig?
• Welche Lieferanten haben Offerten eingereicht?
• Welcher Lieferant wurde ausgewählt und warum?
• Wer hat geprüft und freigegeben?
• Wurde die Bestellung ausgelöst?
• Wurde die Lieferung bestätigt, falls erforderlich?
• Wurde die zugehörige Rechnung an Finance übergeben?

Das Modul ist besonders sinnvoll, wenn mehrere Lieferantenofferten verglichen werden müssen, eine Freigabe vor der Bestellung erforderlich ist oder Finance eine saubere Verbindung zwischen Bestellung und späterer Rechnung benötigt.

Rollen

Welche Buttons sichtbar sind und welche Felder bearbeitet werden können, hängt von Benutzer, Rollen, Status, Mandant und Konfiguration ab.

Typische Rollen sind:

• Requestor: erstellt die Purchase Order und beschreibt den Einkaufsgrund.
• Division Head: prüft die Anforderung aus Sicht der Fachabteilung.
• Head of Finance: prüft finanzielle Aspekte und Budgetauswirkungen.
• Managing Director: gibt die Bestellung auf höherer Stufe frei.
• Ordering user: löst die Bestellung aus und verfolgt Lieferung und Rechnung.
• Finance: erhält die zugehörige Rechnung und verarbeitet sie weiter.
• Administrator: kann je nach Berechtigung mehr Objekte sehen und bearbeiten.

Die konkrete Rollenbezeichnung kann je Installation abweichen. Im Standardprofil sind die Workflow-Felder Requestor, Division Head, Head of Finance, Managing Director und Ordering vorgesehen.

Purchase Orders öffnen

Purchase Orders werden aus dem Purchase-Order-Modul geöffnet, wenn es für den Mandanten aktiv ist und der Benutzer die nötigen Rechte besitzt.

Dashboard:

/invoice/purchase_order/dashboard

Detailseite:

/invoice/purchase_order/details?id=<object-id>

Im Dashboard können Benutzer neue Purchase Orders erstellen, bestehende öffnen, suchen, filtern, Ansichten wechseln und Workflow-Aufgaben weiterbearbeiten.

Dashboard

Das Purchase-Order-Dashboard ist die Arbeitsliste für Bestellungen. Es zeigt Purchase Orders abhängig von Berechtigungen, Mandant, Filter und Status.

Typische Informationen sind:

• aktueller Workflow-Status,
• Titel,
• PO-Nummer,
• bevorzugter Lieferant,
• Bestellart,
• Zahlungstyp,
• Betrag und Währung,
• gewünschter Liefertermin,
• Bestelldatum,
• aktive zuständige Person,
• Stellvertretungshinweise, falls aktiv.

Das Dashboard unterstützt Tabellen- und kompakte Ansichten. Auf mobilen Geräten wird standardmäßig eine kompaktere Ansicht verwendet.

Das Dashboard kombiniert Statuskacheln, Suchbereich, Spaltenfilter, KI-Optionen, Tabellenaktionen und die Bestell-Arbeitsliste.

Dashboard-Filter

Das Dashboard bietet Schnellfilter für typische Arbeitssituationen. Die konkrete Anzeige hängt von der Konfiguration ab.

Unterstützte Filter sind unter anderem:

• My drafts: Purchase Orders in Vorbereitung.
• In progress: Purchase Orders in Prüfung oder Freigabe.
• Ordering and delivery: freigegebene Purchase Orders, die bestellt, geliefert oder nachverfolgt werden müssen.
• Invoice open: Purchase Orders, bei denen die Rechnungsübergabe an Finance noch fehlt.
• Problems: abgelehnte, ungültige, fehlerhafte oder blockierte Fälle.
• Wait on delivery: Lieferbestellungen, bei denen die Lieferung noch nicht bestätigt ist.
• Invoice missing: Purchase Orders, bei denen eine Rechnung erwartet wird, aber noch keine Relation besteht.

Der Suchbereich steuert, wo gesucht wird. Nur offene beschränkt die Arbeitsliste auf aktive Purchase Orders mit offenem Follow-up. Alle Bestellungen berücksichtigt auch abgeschlossene, geschlossene oder sonst nicht offene Purchase Orders, sofern der Benutzer darauf berechtigt ist.

Zusätzlich stehen Suche und Spaltenfilter zur Verfügung, zum Beispiel für Lieferant, Belegnummer, Zuständige, Betragsbereich oder Datum.

Die Tabelle kombiniert Filter, sichtbare Fachfelder, Zeilenaktionen, Spaltenauswahl und Export. Typische Spalten sind Status, PO-Nummer, Datum, letzte Information, Lieferant, Währung, Betrag, Bestellabteilung, PO-Typ, Zahlungsart, aktuelle zuständige Person und Buchhaltungsmandant. Über das Spaltenmenü wird gesteuert, welche Felder angezeigt werden; über Export kann die Trefferliste zum Beispiel kopiert oder als CSV/Excel ausgegeben werden.

Neue Purchase Order erstellen

Eine neue Purchase Order wird im Dashboard über New Purchase Order erstellt.

Vor dem Start des Workflows müssen die wichtigsten Kopfdaten gepflegt werden. Je nach Konfiguration können Pflichtfelder abweichen. Im Standard sind vor allem diese Angaben relevant:

• Antragsteller,
• PO-Datum,
• Titel,
• PO-Typ,
• Bestellabteilung,
• Einkaufsgrund,
• bevorzugter Lieferant,
• Buchhaltungsmandant.

Die PO-Nummer wird vom System geführt und ist nach der Vergabe schreibgeschützt.

Kopfdaten

Die Kopfdaten beschreiben den Geschäftsfall.

Wichtige Felder sind:

• Requestor: Benutzer, der den Einkauf beantragt.
• PO Date: Datum der Purchase Order.
• Title: kurzer fachlicher Titel.
• PO Number: generierte oder vergebene Bestellnummer.
• PO Type: steuert, ob eine Lieferbestätigung relevant ist. Standardwerte sind no delivery und delivery.
• Payment Type: beschreibt die Zahlungsart, zum Beispiel Bill, Prepayed oder Partial Pay.
• Ordering department: verantwortliche Abteilung oder Kontierungsbereich.
• Order by: geplanter Bestellkanal, zum Beispiel Mail, Telefon, Post oder sonstig.
• Requested Arrival: gewünschter Liefer- oder Ankunftstermin.
• Reason for purchasing: Begründung des Einkaufs. Dieses Feld ist für Freigeber besonders wichtig.

Zusätzlich kann ein Post-it-Feld für kurze Hinweise vorhanden sein.

Das Order-Formular kombiniert Aktionen, Workflow-Fortschritt, Kopfdaten, Bestellgrund, Lieferantenofferten, Anhänge und den Aktivitäts-Feed.

Lieferantenofferten

Das Standardformular unterstützt bis zu drei Lieferantenbereiche:

• Vendor 1
• Vendor 2
• Vendor 3

Jeder Bereich enthält Lieferanten- und Offertdaten:

• Firma,
• Adressnummer,
• Straße,
• PLZ / Ort,
• Land,
• Telefon,
• E-Mail,
• Konditionen,
• Beschreibung,
• Währung,
• Währungskurs,
• Total,
• Total in CHF.

Die Adressnummer verbindet den erkannten oder ausgewählten Lieferanten mit den Adressstammdaten. Ist sie leer, wurde kein Stammdatensatz erkannt oder die Adresse wurde manuell ohne Referenz erfasst.

Im Lieferantenvergleich prüfen Benutzer die extrahierten Adressdaten, Konditionen, Währung, Kurs, Totale, Bestpreis-Markierung und Positionen pro Anbieter.

Lieferantenadresse auswählen oder speichern

Lieferantendaten können manuell erfasst oder über Wertelisten aus den Stammdaten übernommen werden. Wird ein Lieferant ausgewählt, können Adresse, Adressnummer, Telefon und E-Mail in den Vendor-Bereich kopiert werden.

Beim Feld Adressnummer gibt es pro Lieferant eine Aktion Save vendor address. Diese sollte nur verwendet werden, wenn die Lieferantendaten geprüft wurden. Je nach Backend und Berechtigung kann dadurch ein Lieferantenstammsatz erstellt oder aktualisiert werden.

Vor dem Speichern prüfen:

• Stimmt der Lieferantenname?
• Gehört die Adresse zur richtigen juristischen Einheit?
• Sind PLZ, Ort und Land plausibel?
• Sind Telefon und E-Mail echte Lieferantenkontakte?
• Gehört eine vorhandene Adressnummer zum richtigen Lieferanten?

Offerten hochladen

Das Formular enthält Uploadbereiche für Lieferantenofferten. Eine hochgeladene Offerte wird als Anhang gespeichert und mit der Purchase Order verknüpft.

Wenn die automatische Extraktion aktiv ist, kann der Upload die Analyse für den jeweiligen Lieferantenslot starten. Dabei versucht das System, Lieferantendaten, Konditionen, Währung, Totale und Positionen aus der Offerte zu lesen.

PDF-Dateien sind der häufigste Dokumenttyp. Gescannte PDFs benötigen OCR und können länger dauern oder ungenauere Ergebnisse liefern.

Jede Lieferantenofferte zeigt die hochgeladene Datei, den Extraktionsstatus, die Upload-Aktion und die KI-Reanalyse für den betroffenen Lieferantenslot.

KI-gestützte Offertenanalyse

Die KI-Analyse kann unter anderem folgende Daten auslesen:

• Titel der Purchase Order,
• PO-Typ,
• Zahlungstyp,
• Lieferantenname und Adresse,
• E-Mail und Telefon,
• Lieferzeit,
• Konditionen,
• Offertbeschreibung,
• Währung,
• Offerttotal,
• Frachtinformationen,
• Hinweise auf Vorauszahlung,
• Artikel- oder Leistungspositionen.

Nur die erste Offerte darf Kopfdaten wie Titel, PO-Typ und Zahlungstyp vorschlagen. Spätere Offerten gelten als Alternativen und sollen diese Kopfdaten nicht überschreiben.

Die KI-Analyse ist eine Arbeitshilfe. Benutzer müssen die Resultate prüfen, bevor sie den Workflow fortsetzen.

Infografik benötigt: KI-Extraktionsfluss
Einfache Grafik mit hochgeladener Offerte, Text/OCR-Extraktion, Lieferantenstammdaten-Abgleich, Vendor-Feld-Update, Positionsextraktion und Benutzerprüfung.

Reanalyse

Wenn die Extraktion unvollständig oder falsch war, kann ein Lieferantenangebot erneut analysiert werden.

Bei einer vollständigen Reanalyse eines Vendor-Slots können bestehende Felder und Positionen dieses Lieferanten zuerst geleert und danach neu geschrieben werden. Daten der anderen Vendor-Slots bleiben erhalten.

Reanalyse ist sinnvoll, wenn:

• zuerst das falsche Dokument hochgeladen wurde,
• OCR nach einem erneuten Lauf bessere Texte liefert,
• Lieferantendaten fehlen,
• Positionen unvollständig sind,
• sich die Offerte geändert hat.

Benutzer sollten beachten, dass manuell korrigierte Daten im betroffenen Vendor-Slot je nach Modus ersetzt oder gelöscht werden können.

Positionen

PO-Positionen werden getrennt von den Kopfdaten gespeichert und im Formular nach Lieferant gruppiert angezeigt.

Typische Positionsfelder sind:

• Vendor-Slot,
• Artikelnummer,
• Beschreibung,
• Konto,
• Kostenstelle,
• Menge,
• Einheit,
• Einzelpreis,
• Steuer oder Zuschlag,
• Netto,
• Brutto,
• Kommentar.

Positionen können aus Offerten extrahiert oder manuell gepflegt werden. Konto und Kostenstelle verwenden vorhandene mandantenspezifische Stammdaten, falls verfügbar.

Das Positionsraster gruppiert Zeilen pro Lieferant. Benutzer prüfen oder korrigieren Artikel, Konto, Kostenstelle, Menge, Einzelpreis, Zeilentotal und Lieferantentotal.

Lieferanten vergleichen

Die drei Vendor-Bereiche werden nebeneinander dargestellt. Dadurch können Benutzer vergleichen:

• Lieferantenidentität,
• Konditionen,
• Lieferinformationen,
• Gesamtbetrag,
• Währung,
• CHF-Umrechnung,
• Positionen,
• Frachtbedingungen,
• Zahlungshinweise.

Der bevorzugte Lieferant muss im Feld Preferred Vendor explizit gewählt werden. Diese Entscheidung ist wichtig für Freigabe, Bestellung und spätere Rechnungszuordnung.

Budgetinformationen

Wenn der Benutzer berechtigt ist und der Mandant dies unterstützt, zeigt die Detailseite eine Budgetzusammenfassung.

Je nach Konfiguration werden angezeigt:

• Konto- oder Kostenstellenkontext,
• Budget,
• bereits verbrauchter Betrag,
• Restbudget,
• Warnfarben bei knappen oder überschrittenen Budgets.

Budgetinformationen dienen als Entscheidungshilfe. Wenn Budgetdaten fehlen oder unklar sind, sollte Finance eingebunden werden.

Anhänge

Purchase Orders unterstützen zusätzliche Anhänge. Der Anhangsbereich erlaubt Drag-and-drop-Upload und zeigt verknüpfte Dateien mit Vorschau, Details, Download und Löschen.

Typische Anhänge sind:

• Lieferantenofferten,
• Rückfragen,
• Zeichnungen,
• Spezifikationen,
• freigaberelevante Unterlagen,
• Auftragsbestätigungen,
• Korrespondenz.

Anhänge sollten nur gelöscht werden, wenn sie nicht für Nachvollziehbarkeit oder Prüfung benötigt werden.

Feed und Verlauf

Die Detailseite enthält einen Feed mit Audit-Trail-Einträgen, Kommentaren, Workflow-Ereignissen und Prozessinformationen.

Typische Feed-Einträge sind:

• Purchase Order erstellt,
• Workflow gestartet,
• geprüft,
• freigegeben,
• bestellt,
• Rechnung an Finance übermittelt,
• als bezahlt markiert,
• abgelehnt,
• ungültig gesetzt,
• automatische Extraktion durchgeführt.

Der Feed enthält sowohl Systemeinträge als auch manuelle Kommentare von Mitarbeitenden. Systemeinträge dokumentieren, was automatisch oder durch Workflow-Aktionen passiert ist, zum Beispiel wer die Purchase Order erstellt, die Extraktion gestartet, die Bestellmail versendet oder die Rechnung an Finance übergeben hat. Kommentare sind manuell erfasste Hinweise, Rückfragen oder Entscheidungen für andere Mitarbeitende.

Der Feed hilft zu verstehen, warum ein Objekt im aktuellen Status ist, wer die letzte relevante Aktion ausgeführt hat und welche fachlichen Klärungen während der Bearbeitung ergänzt wurden.

Workflow-Status

Das Standardprofil unterstützt diese Status:

Status	Bedeutung
00 imported	Technischer Initial- oder Importstatus.
01 new	Neue oder noch nicht eingereichte Purchase Order.
02 in review	Wartet auf fachliche Prüfung.
03 in approval	Wartet auf Finance- oder Freigabeschritt.
05 controlling	Wartet auf Controlling- oder Managementprüfung.
04 approved	Purchase Order freigegeben.
04 approved controlling	Nach Controlling-Schritt freigegeben.
07 ordered	Bestellung wurde ausgelöst.
08 ready to pay	Zugehörige Rechnung ist für Zahlungsschritt bereit.
10 ready for export	Bereit für ERP-Export oder Weiterverarbeitung.
97 rejected	Abgelehnt.
98 invalid	Als ungültig markiert.
99 error	Technischer oder fachlicher Fehler.

Die konkreten Übergänge und Buttontexte können je Installation konfiguriert sein.

Standardablauf

Ein typischer Ablauf:

1. Antragsteller erstellt die Purchase Order.
2. Lieferantenofferten werden hochgeladen oder erfasst.
3. KI-Extraktion füllt, wenn aktiv, Lieferanten- und Positionsdaten.
4. Antragsteller prüft und korrigiert die Daten.
5. Bevorzugter Lieferant wird gewählt.
6. Purchase Order wird eingereicht.
7. Division Head prüft.
8. Finance prüft Budget, Kontierung und Plausibilität.
9. Management gibt frei, falls erforderlich.
10. Ordering löst die Bestellung aus.
11. Lieferung wird bestätigt, falls erforderlich.
12. Zugehörige Rechnung wird hochgeladen und an Finance übergeben.
13. Finance verarbeitet Zahlung oder Export weiter.

Nicht jede Installation verwendet jeden Schritt.

Prozessvarianten

Der Ablauf verzweigt je nach Liefer- und Zahlungsart. Diese Varianten sind für Schulung und Support hilfreich, weil sie zeigen, wann Finance die Rechnung erhält und ob eine Lieferbestätigung Teil des Prozesses ist.

Keine Lieferung oder Lieferentscheid

Diese Variante gilt, wenn keine separate Lieferbestätigung nötig ist oder der Lieferentscheid vor der Rechnungsübergabe explizit geprüft wird.

Normale Rechnung

Diese Variante gilt, wenn die Lieferantenrechnung nach ausgelöster Bestellung und bestätigter Lieferung erwartet wird.

Vorauszahlung

Diese Variante gilt, wenn Finance eine Vorauszahlungsrechnung erhält, bevor die Lieferung abgeschlossen ist. Die Liefernachverfolgung bleibt nach der Rechnungsübergabe sichtbar.

Proforma Teilzahlung

Diese Variante gilt, wenn zuerst eine Proforma- oder Teilzahlungsrechnung an Finance geht und später eine Schlussrechnung erwartet wird.

Der Workflowstatus steuert, welche Aktion verfügbar ist, wer aktiv zuständig ist und ob die Purchase Order noch bearbeitet wird, auf Follow-up wartet, für Folgeprozesse bereit ist oder als Ausnahme geschlossen wurde.

Als zuständige Person arbeiten

Die aktive zuständige Person hängt vom Status ab:

• In Review ist der erste Assignee aktiv.
• In Approval ist der zweite Assignee aktiv; falls leer, kann der erste verwendet werden.
• In Controlling ist der dritte Assignee aktiv; Fallbacks können vorherige Assignees nutzen.
• In Ordered- und Folgestatus ist der Ordering-Assignee relevant.

Wenn Stellvertretungen aktiv sind, kann das Dashboard Stellvertretungshinweise anzeigen und Objekte der vertretenen Person einblenden.

Bestellung auslösen

Nach der Freigabe kann die Bestellung ausgelöst werden. Der Bestellkanal wird im Feld Order by gespeichert.

Vor der Bestellung prüfen:

• Ist der bevorzugte Lieferant korrekt?
• Stimmen Betrag und Währung?
• Sind Lieferanforderungen klar?
• Ist der Zahlungstyp korrekt?
• Sind Lieferanten-E-Mail und Kontakt korrekt?
• Sind alle Freigaben abgeschlossen?

Bestellarten

Der Bestellkanal wird im Feld Order by gespeichert. Das Standardprofil unterstützt diese Werte:

Bestellart	Bedeutung
Mail	Die Bestellung wird aus dem PO-E-Mail-Dialog per E-Mail an den bevorzugten Lieferanten gesendet.
Manual	Die Bestellung wird ausserhalb des Systems ausgelöst, zum Beispiel telefonisch, mündlich oder in einem anderen Einkaufstool.
AI	Reserviert für automatisierte oder assistierte Bestellszenarien, abhängig von der Installation.
Abacus	Reserviert für ERP- oder Abacus-gestützte Bestellszenarien, abhängig von der Installation.

Welche Buttons und Folgeschritte sichtbar sind, kann je Installation konfiguriert sein. Der E-Mail-Dialog setzt voraus, dass die Bestellart Mail ist.

Bestellen per E-Mail

Wenn Order by auf Mail steht, kann die zuständige Person den Purchase-Order-E-Mail-Dialog öffnen. Der Dialog bereitet eine E-Mail an den bevorzugten Lieferanten vor und verwendet die E-Mail-Adresse aus dem gewählten Lieferantenslot.

Der Empfänger wird aus dem bevorzugten Lieferanten vorbelegt:

• Vendor 1 verwendet cq_po_vendor1_email,
• Vendor 2 verwendet cq_po_vendor2_email,
• Vendor 3 verwendet cq_po_vendor3_email.

Der bevorzugte Lieferant kommt aus dem Feld Preferred Vendor. Wenn keine Lieferanten-E-Mail vorhanden ist, müssen die Lieferantendaten vor dem Versand ergänzt oder korrigiert werden.

E-Mail-Templates

Purchase-Order-E-Mail-Templates werden als cq_email_template-Objekte im konfigurierten Template-Ordner gespeichert. Standardmässig wird der Ordner $config$email_template mit dem Anzeigenamen E-mail templates verwendet. Ordner, Standardbetreff und Standardtext können über config['invoice']['purchase_order_mail'] konfiguriert werden.

Im Dialog können Templates ausgewählt, erstellt, aktualisiert oder gelöscht werden. Ein ausgewähltes Template füllt Betreff und Nachricht. Ohne gewähltes Template verwendet der Dialog Betreff und Nachricht aus der Konfiguration.

Standardbetreff:

Purchase order <%po_number%>

Standardtext:

<p>Dear Sir or Madam</p>
<p>Please find attached our purchase order request.</p>
<p>Best regards<br><%requester%></p>

Anhänge und Verlauf

Im Dialog kann der Offertenanhang des bevorzugten Lieferanten ausgewählt werden. Beim Versand wird diese Offerte an die ausgehende E-Mail angehängt.

Nach erfolgreichem Versand erstellt centraQuest eine .eml-Datei mit einem Namen wie Purchase order mail <po_number>.eml, speichert sie als PO-Anhang mit Dokumenttyp Purchase order mail, verknüpft sie mit der Purchase Order und schreibt einen Verlaufseintrag. Die Purchase Order wird auf 07 ordered gesetzt.

E-Mail-Variablen

Variablen können in Betreff und Nachricht mit der Syntax <%variable_name%> verwendet werden.

Variable	Wert
<%po_number%>	PO-Nummer aus cq_document_no, cq_accounting_int_ref, Objektname oder Objekt-ID.
<%po_title%>	Titel der Purchase Order oder Objektname.
<%vendor%>	Firmenname des bevorzugten Lieferanten oder Fallback wie Vendor 1.
<%requester%>	Antragsteller aus cq_po_requestor, Objektersteller oder aktueller Benutzer.
<%client_accounting%>	Buchhaltungsmandant aus cq_client_accounting.

Lieferbestätigung

Purchase Orders mit PO-Typ delivery können eine Lieferbestätigung verlangen, bevor die Rechnung an Finance übergeben werden kann.

Wenn eine Lieferbestätigung erforderlich ist, zeigt die Follow-up-Leiste einen Liefer-Schritt. Benutzer können die Lieferung bestätigen und ein Lieferdatum setzen. Wird kein Datum manuell gesetzt, kann die Oberfläche beim Aktivieren der Bestätigung das Tagesdatum verwenden.

Bei Purchase Orders ohne Lieferpflicht kann der Rechnungsupload ohne Lieferbestätigung verfügbar sein.

Nachdem die Lieferung mit Delivered bestätigt wurde, kann die zuständige Person über Submit invoice to Finance die Lieferantenrechnung hochladen. Nach dem Hochladen der Rechnung wird Finance per E-Mail informiert, dass die Rechnung bezahlt werden kann.

Rechnung an Finance übergeben

Nach der Bestellung kann die zugehörige Lieferantenrechnung auf der PO-Detailseite hochgeladen werden. Die Finance-Dropzone akzeptiert PDF- und Bilddateien und wird im Follow-up-Bereich als Submit invoice to Finance angezeigt.

Je nach Zahlungstyp und Konfiguration gibt es unterschiedliche Rechnungskontexte:

• normale Finance-Rechnung,
• Vorauszahlungsrechnung,
• Schlussrechnung.

Bei Teilzahlung oder Vorauszahlung kann der Prozess mehrere Rechnungsschritte enthalten:

• Vorauszahlungsrechnung,
• Lieferbestätigung,
• Schlussrechnung.

Nach dem Upload wird die Datei gespeichert, mit der Purchase Order verknüpft und der Status gemäß Prozess aktualisiert.

Zahlungstypen

Die Zahlungstypen beeinflussen den Folgeprozess:

• Bill: normale Rechnung nach Bestellung oder Lieferung.
• Prepayed: Vorauszahlungsprozess; Rechnung kann vor Lieferung nötig sein.
• Partial Pay: geteilter Prozess mit Vorauszahlung und Schlussrechnung.
• Paid: nur verwenden, wenn klar ist, dass bereits bezahlt wurde; Verfügbarkeit abhängig von Konfiguration.

Der Zahlungstyp sollte sorgfältig gewählt werden, weil er die erwarteten Folgeschritte steuert.

Suche und Tabellenarbeit

Das Dashboard unterstützt Suche und Filterung. Je nach Konfiguration kann nach Lieferant, Belegnummer, Zuständigen, Betrag und Datum gesucht werden.

In der Tabelle können Benutzer typischerweise:

• Purchase Order öffnen,
• Zeilen markieren,
• Kontextaktionen verwenden,
• Status-Badges sehen,
• überfällige oder bald fällige Bestelldaten erkennen,
• aktive Zuständige erkennen,
• zwischen offenen und abgeschlossenen Ansichten wechseln.

Berechtigungen und Sichtbarkeit

Benutzer sehen nur Purchase Orders, die durch Rollen, Objektberechtigungen, Workflow-Zuständigkeit, Stellvertretung oder Administratorrechte erlaubt sind.

Sichtbarkeit kann abhängen von:

• Buchhaltungsmandant,
• Objekt-ACL,
• Antragsteller,
• Ersteller,
• aktivem Assignee,
• Stellvertretung,
• Finance- oder Buchhaltungsrollen,
• Administratorrollen,
• aktiven Dashboard-Filtern.

Wenn eine Purchase Order nicht sichtbar ist, zuerst Mandant, Filter, Rollen und aktuelle Workflow-Zuständigkeit prüfen.

Infografik benötigt: Sichtbarkeit und Berechtigungen
Kompakte Grafik, wie Buchhaltungsmandant, Rollen, Objekt-ACL, Requestor/Creator, Assignee, Stellvertretung und Dashboard-Filter die Sichtbarkeit bestimmen.

Checkliste vor Einreichung

Vor dem Einreichen prüfen:

• Titel beschreibt den Einkauf klar.
• Antragsteller ist korrekt.
• Bestellabteilung ist korrekt.
• Einkaufsgrund ist verständlich.
• Mindestens eine Offerte ist erfasst oder hochgeladen.
• Lieferantendaten sind plausibel.
• Bevorzugter Lieferant ist gewählt.
• Beträge und Währungen stimmen.
• Positionen sind ausreichend gepflegt.
• Zahlungstyp ist korrekt.
• Erforderliche Anhänge sind vorhanden.

Checkliste vor Freigabe

Vor der Freigabe prüfen:

• Einkauf ist begründet.
• Gewählter Lieferant ist plausibel.
• Betrag entspricht der Offerte.
• Währung und CHF-Total sind plausibel.
• Budgetinformationen wurden geprüft, falls vorhanden.
• Zahlungstyp und Lieferanforderungen stimmen.
• Bestellkanal ist sinnvoll.
• Abweichungen oder Risiken sind im Feed dokumentiert.

Checkliste vor Bestellung

Vor dem Auslösen der Bestellung prüfen:

• Freigabe ist vollständig.
• Bevorzugter Lieferant und E-Mail stimmen.
• Bestellart und gewünschter Liefertermin stimmen.
• Lieferantenkonditionen sind akzeptabel.
• Die gewählte Offerte ist die richtige.
• Der spätere Rechnungsweg ist klar, besonders bei Voraus- oder Teilzahlung.

Häufige Probleme

Keine Purchase Order sichtbar

Mandant, Filter, Rolle, Objektberechtigung, Workflow-Zuständigkeit und Stellvertretung prüfen.

Formular ist schreibgeschützt

Der Status kann Bearbeitung sperren oder der Benutzer ist nicht aktive zuständige Person. Einzelne Felder können trotzdem für bestimmte Rollen editierbar bleiben.

KI findet keine Positionen

Das Dokument enthält eventuell zu wenig maschinenlesbaren Text, ist gescannt oder hat ein schwieriges Tabellenlayout. Reanalyse versuchen oder Positionen manuell ergänzen.

Falscher Lieferant wurde zugeordnet

Adressnummer und Lieferantenfelder prüfen. Wenn die Adressnummer zum falschen Lieferanten gehört, den Vendor-Bereich korrigieren, bevor Daten gespeichert oder weiterverwendet werden.

Währung oder Total stimmt nicht

Offerte prüfen. Die KI bevorzugt explizite Dokumenttotale und erkennt Währungen wie CHF, EUR, USD und GBP. Bei mehreren Totalen kann manuelle Korrektur nötig sein.

Rechnungsupload ist deaktiviert

Die PO ist eventuell noch nicht bestellt, die Lieferbestätigung fehlt oder der Benutzer darf den Follow-up-Schritt nicht ausführen.

Workflow-Button fehlt

Der Button kann fehlen, weil der Status nicht passt, der Benutzer nicht zuständig ist, Pflichtfelder fehlen oder die Mandantenkonfiguration die Aktion deaktiviert.

Best Practices

• Klare, spezifische Titel verwenden.
• Pro Vendor-Slot eine Lieferantenofferte verwenden.
• KI-Daten vor Einreichung prüfen.
• Lieferantenstammdaten nicht aus unsicheren OCR-Ergebnissen speichern.
• Bevorzugten Lieferanten explizit wählen.
• Positionen sauber genug für Finance und Budgetprüfung halten.
• Begründungen und Besonderheiten im Feed dokumentieren.
• Lieferung nur bestätigen, wenn Ware oder Leistung erhalten wurde.
• Rechnung über die PO-Detailseite hochladen, damit die Relation erhalten bleibt.
• Bei Teilzahlung oder Vorauszahlung die erwartete Rechnungsreihenfolge prüfen.

Datenbereiche

Bereich	Typische Felder
Kopfdaten	Requestor, PO Date, Title, PO Number, PO Type, Payment Type, Department, Reason
Workflow	Division Head, Head of Finance, Managing Director, Ordering, Status
Vendor 1-3	Firma, Adressnummer, Adresse, Kontakt, Konditionen, Beschreibung, Währung, Total
Entscheidung	Preferred Vendor, Ordering Date, Delivered
Betrag	Währung, Brutto, CHF-Totale
Positionen	Artikelnummer, Beschreibung, Konto, Kostenstelle, Menge, Einzelpreis, Netto, Brutto
Anhänge	Offerten, Zusatzdokumente, Auftragsbestätigungen, Rechnungen
Feed	Kommentare, Workflow-Ereignisse, Extraktionsinfos, Warnungen

Purchase to Pay

Purchase to Pay verbindet Beschaffung und Zahlung. Purchase Order steuert die Einkaufsseite; die spätere Lieferantenrechnung bildet die Brücke zu Invoice oder Finance. Wird eine Rechnung auf der PO-Detailseite hochgeladen, erstellt das System eine Relation zwischen Purchase Order und Rechnungsanhang oder Rechnungsobjekt.

Wenn eine Rechnung unabhängig eintrifft und eine PO-Nummer enthält, kann der Invoice-Prozess versuchen, die passende Purchase Order im gleichen Mandanten zu finden. Bei Treffer kann die Rechnung verknüpft und je nach Konfiguration Kontierungs- oder Freigabekontext übernommen werden. Treffer in anderen Mandanten werden aus Sicherheitsgründen nicht automatisch verknüpft.

Zusammenfassung

Purchase Order bildet den kontrollierten Einkaufsworkflow in centraQuest ab. Benutzer erstellen eine PO, sammeln Lieferantenofferten, lassen sich bei der Extraktion unterstützen, vergleichen Lieferanten, wählen einen bevorzugten Anbieter, führen die Freigabe durch, lösen die Bestellung aus, bestätigen bei Bedarf die Lieferung und übergeben die Rechnung an Finance.

Der größte Nutzen entsteht, wenn Lieferantendaten, Positionen, Entscheidungen und Kommentare sauber gepflegt werden. So bleibt der Einkaufsfall vom Antrag bis zur Rechnungsverarbeitung nachvollziehbar.