SFTP-Postfach + filehubIDP

Welche Felder ausgelesen werden, richtet sich nach der erkannten Dokumentart (Systemprofil der Art, optional mit einem Mandantenprofil darüber).

Beträge bleiben Zeichenketten mit Währung daneben — nie Gleitkommazahlen. Je Feld stehen Methode und Absicherung dabei (…{feld}.currency, …{feld}.method).

Felder für Folge-Nodes: Im Feldwähler eines Folge-Nodes stehen die Felder je Dokumentklasse — idp.{dokumentklasse}.kopf.{abschnitt}.{feld} (z. B. idp.rechnung.kopf.beleg.invoice.header.id; der Abschnitt — Beleg, Leistender, Leistungsempfänger, Zahlung, Summen — kommt aus dem Katalog des Dienstes und ist wie die Klasse Navigation, kein Filter), Positionen unter …positionen.{feld} (eine Liste über alle Zeilen, für mehrwertige Merkmale) und Kopfgruppen wie die Steueraufschlüsselung unter …gruppen.{gruppe}.{feld}. Die Dokumentklasse im Pfad ist Navigation, kein Filter: aufgelöst wird das Feld. Eine Gutschrift liefert unter dem Rechnungspfad dieselbe Rechnungsnummer; ein Beleg, der das Feld nicht trägt, liefert leer. Der Baum kommt aus dem Katalog des Dienstes („Katalog aktualisieren" im Node); ein Feld, das der Dienst nicht mehr führt, verschwindet aus dem Baum, ein gespeicherter Pfad bleibt gültig und liefert leer. Rohform ohne Klasse: idp.fields.{feld}, idp.positionen.{feld}.

Beträge und Mengen tragen ihr Vorzeichen (Vertrag 2.0.0): eine Gutschrift kann als -69.42 ankommen, und eine Rechnung (380) mit negativen Summen ist eine Minderung. Ob der Beleg erhöht oder mindert, sagt idp.belegrichtung (erhoeht, mindert, widerspruch) — aus Belegtyp und Vorzeichen abgeleitet, nie aus einem allein. Ein Router mit idp.belegrichtung gleich widerspruch (oder leer) hält den Beleg vor der Buchung zurück; der Belegtyp (idp.dokumenttyp) bleibt, was der Aussteller geschrieben hat.

Der Katalog der Dokumentarten wird laufend erweitert. Ein Dokument, dessen Art noch nicht erkannt wird, kommt als unbekannt an und lässt sich per Router in einen eigenen Zweig lenken.

Jede filehubIDP-Node trennt intern — der Dienst trennt, bevor er liest. Ein Stapel wird deshalb auch hier zu mehreren Dokumenten; ein Trennblatt lässt sich behalten oder entfernen.

Ergebnis unter idp.dokumentklasse, idp.dokumenttyp und idp.klassifikation: uebernehmen, wenn die Erkennung sicher war, sonst pruefen. Ein Router mit idp.klassifikation gleich pruefen schickt unsichere Belege in einen Prüfzweig.

Der Katalog der Dokumentarten wird laufend erweitert. Ein Dokument, dessen Art noch nicht erkannt wird, kommt als unbekannt an und lässt sich per Router in einen eigenen Zweig lenken.

Jede filehubIDP-Node trennt intern — der Dienst trennt, bevor er liest. Ein Stapel wird deshalb auch hier zu mehreren Dokumenten; ein Trennblatt lässt sich behalten oder entfernen.

Entscheidung unter idp.gate.entscheidung. Solange der Shadow Mode gilt, wird nichts automatisch gebucht; sichtpruefung ist der Normalfall eines Belegs ohne Bestellung.

Felder für Folge-Nodes: Im Feldwähler eines Folge-Nodes stehen die Felder je Dokumentklasse — idp.{dokumentklasse}.kopf.{abschnitt}.{feld} (z. B. idp.rechnung.kopf.beleg.invoice.header.id; der Abschnitt — Beleg, Leistender, Leistungsempfänger, Zahlung, Summen — kommt aus dem Katalog des Dienstes und ist wie die Klasse Navigation, kein Filter), Positionen unter …positionen.{feld} (eine Liste über alle Zeilen, für mehrwertige Merkmale) und Kopfgruppen wie die Steueraufschlüsselung unter …gruppen.{gruppe}.{feld}. Die Dokumentklasse im Pfad ist Navigation, kein Filter: aufgelöst wird das Feld. Eine Gutschrift liefert unter dem Rechnungspfad dieselbe Rechnungsnummer; ein Beleg, der das Feld nicht trägt, liefert leer. Der Baum kommt aus dem Katalog des Dienstes („Katalog aktualisieren" im Node); ein Feld, das der Dienst nicht mehr führt, verschwindet aus dem Baum, ein gespeicherter Pfad bleibt gültig und liefert leer. Rohform ohne Klasse: idp.fields.{feld}, idp.positionen.{feld}.

Jede filehubIDP-Node trennt intern — der Dienst trennt, bevor er liest. Ein Stapel wird deshalb auch hier zu mehreren Dokumenten; ein Trennblatt lässt sich behalten oder entfernen.

Übergibt den Stapel an filehubIDP und gibt je erkanntem Beleg ein eigenes PDF weiter. Ein Trennblatt (z. B. das Amagno-Deckblatt) muss vor jedem Beleg liegen und bei mindestens 300 dpi gescannt sein.

Trennmerkmal: Code 39, Code 128, Data Matrix, EAN-8, EAN-13, Interleaved 2 of 5, PDF417 oder QR-Code — immer mit dem Wert des Trennblatt-Codes, denn eine Codeart allein trennt nicht (sonst wäre jede Rechnung mit GiroCode ein Trennblatt). Oder ein fixes Trennblatt: hochladen, filehubIDP liest seinen Code, jede Seite mit diesem Code trennt. Semantik (Vorgabe): filehubIDP entscheidet — bekannte Trennblätter, sonst ein Dokument; die Trennung nach Inhalt ist in Arbeit. Außer bei Semantik: Trennblatt behalten (Vorgabe) oder entfernen.

Womit getrennt wurde, steht je Beleg unter idp.trennmethode: trennblatt, codewechsel, seitenzahl, manuell — oder einzeldokument, wenn keine Trennstelle gefunden wurde. Ein mehrseitiges einzeldokument aus einem Eingang mit Trennblättern ist der Stapel, dessen Blatt nicht gelesen wurde: ein Router mit idp.trennmethode gleich einzeldokument (und idp.seitenzahl) schickt ihn in einen Prüfzweig. Leer heißt: von einem filehubIDP-Stand vor Vertrag 1.1.0 getrennt — wie unsicher behandeln.

Die PDFs der Belege schneidet filehubIDP selbst (Seiten übernommen, nicht neu kodiert); nur wenn der Dienst keines liefert, schneidet filehub aus dem Original. Das Original bleibt das maßgebliche Stück.

Hinter einen Router für unsichere Belege setzen. Die Archivzeile dieser Node ist der Prüfauftrag: dort öffnet die Lupe die Prüfoberfläche, und „Geprüft — weiterverarbeiten" startet den Workflow, der mit „Nach Prüfung fortsetzen" und demselben Prüfkanal beginnt — mit dem aktuellen Stand, also samt Korrekturen und neuem Schnitt.