Dokumentsynchronisierung

Was sich auf dieser Workspace-Seite geändert hat, älteste zuerst. Ein Ereignis nennt ein Dokument, nie dessen Inhalt: Lesen Sie das Dokument mit der zugehörigen Operation, so erhalten Sie immer seine aktuelle Version. Übergeben Sie nextCursor bei Ihrem nächsten Aufruf als after; solange hasMore true ist, rufen Sie sofort erneut auf. Ereignisse werden 30 Tage aufbewahrt und mindestens einmal zugestellt, dieselbe Änderung kann also zweimal kommen; die neuesten 5 Sekunden warten auf den nächsten Aufruf. Ein Aufrufer mit Lieferantenrolle erhält purchase_order.issued, changed, canceled und rejected, invoice.received, approved, rejected, paid, payment_withdrawn, remittance_sent und credit_applied, invoice.updated (ein Käufer hat die Rechnung zur Prüfung angehalten oder wieder freigegeben: lesen Sie GetInvoiceStatus) sowie credit_note.accepted und rejected. Ein Aufrufer mit Käuferrolle erhält invoice.received und credit_note.received (von einem Lieferanten gesendet); invoice.updated (eine Rechnung wurde freigegeben, von einer Person oder automatisch, oder abgelehnt, oder ihr Lieferant hat Bankdaten bestätigt oder sie gemeldet); invoice.payment (eine Zahlung wurde erfasst oder zurückgezogen, eine Gutschrift hat die Rechnung beglichen, oder eine Zahlung über Pleaxy ist durchgegangen oder fehlgeschlagen: lesen Sie GetInvoiceRemittance); purchase_order.updated (eine Bestellung wurde freigegeben, abgelehnt oder storniert); sowie purchase_order.confirmed und purchase_order.shipped (lesen Sie GetPurchaseOrderFulfillment). Er erhält nur die Dokumenttypen, die seine Einkaufsrolle sehen darf.

Eine ausgestellte Bestellung als Dokument, das Ihr System übernimmt. format=cxml (Standard) ist ein cXML OrderRequest: Typ new, update ab Version 2, delete nach der Stornierung. format=ubl ist eine UBL 2.1 Order oder nach der Stornierung eine OrderCancellation. Beide Parteien werden mit ihren Workspace-IDs genannt. Es ist die Lieferantenkopie, egal wer fragt. Ein Lieferant, dessen Käufer dieselbe PO-ID verwenden, ergänzt ?buyer=<buyer Workspace ID>.

Eine Rechnung als UBL 2.1 Invoice (Typ 380 oder 383 für eine Lastschrift), zum Buchen im ERP des Käufers oder für das Archiv des Lieferanten: ihre Positionen, Rabatte und Zuschläge auf Dokumentebene, Steuern und Einbehalte, Vorauszahlungen, die Zahlungsanweisungen des Lieferanten sowie die PO und der Vertrag, die sie abrechnet. Die Summen stimmen mit dem Rechnungsbetrag überein. Es ist die Lieferantensicht, egal wer fragt: kein Abgleich, keine Befunde, keine Freigaben.

Der Stand einer Rechnung, für das System, das sie gesendet hat, oder das, das sie bezahlt, als ein Status mit den Codes, die E-Rechnungssysteme dafür verwenden. Dasselbe als cXML oder UBL ist GetInvoiceStatusDocument. Es ist die Lieferantensicht, egal wer fragt.

GetInvoiceStatus als Dokument. format=cxml (Standard) ist ein cXML StatusUpdateRequest mit einem InvoiceStatus; format=ubl ist eine UBL 2.1 ApplicationResponse mit den Codes der Peppol Invoice Response und bei einer Ablehnung deren Grund.

Das Zahlungssignal einer Rechnung für die Zahlungszuordnung des Lieferanten: wie und wann der Käufer bezahlt hat, die Referenz, was einbehalten wurde und was beim Lieferanten ankam, sowie die Zahlungsavise, die der Käufer gesendet hat (Notizen und Zahlungsnachweise; GetRemittanceFile lädt einen herunter). Pleaxy erfasst, was der Käufer angibt, und bewegt kein Geld. Nie, wer beim Käufer die Zahlung erfasst hat. Dasselbe als cXML oder UBL ist GetInvoiceRemittanceDocument.

GetInvoiceRemittance als Dokument. format=cxml (Standard) ist ein cXML PaymentRemittanceRequest; format=ubl ist ein UBL 2.1 RemittanceAdvice.

Erfasst Zahlungen, die Ihr ERP oder Bank-Feed bereits außerhalb von Pleaxy geleistet hat - Überweisungen, Schecks, ACH, Karte -, damit jeder Lieferant seine Zahlungsbenachrichtigung, sein Zahlungsavis und sein Sync-Ereignis erhält, ohne dass jemand etwas abtippt. Dabei wird kein Geld bewegt. Jede Zahlung folgt den Regeln von RecordPayment und wird einzeln beantwortet; eine Wiederholung ist unbedenklich (already_recorded). Eine von einem API-Schlüssel freigegebene Rechnung wird weiterhin abgelehnt. note wird zu einer Notiz im Zahlungsavis für den Lieferanten; einen Zahlungsnachweis kann nur eine Person anhängen.

Nur Käufer-API-Schlüssel mit dem Scope payments:record, erzeugt mit einer procurementRole, die Rechnungen bearbeiten kann (administrator oder finance). Eine angemeldete Person verwendet RecordPayment.