eDoc App Online Help
German Dutch English French
Auto Light Dark
Auto Light Dark
German Dutch English French

Endpunktverwaltung

Die Endpunktverwaltung

Elektronisches Belegformat

Sie dient der elektronischen Übertragung und Verarbeitung von Verkaufs- und Service-Rechnungen sowie Verkaufs- und Service-Gutschriften. Diese Dokumentation erläutert seine Verwendung im Belegsendeprofil sowie die relevanten technischen Komponenten für Export und Versandabwicklung über Codeunits.

Im Folgenden wird genauer auf die Felder im Elektronischen Belegformat eingegangen:

  1. Code: Er wird im Belegsendeprofil im Feld "Format" eingetragen. Dieser Code gibt an, welches Format zur Übertragung des Belegs verwendet wird.

  2. Beschreibung:

  3. Verwendung: Die Angabe ist wichtig, um die Belege richtig zu kategorisieren und zu verarbeiten.

  4. Codeunit-ID: Hier wird die Codeunit eingetragen, die je nach Codeunit der Speicherung und Verarbeitung von Daten dient, die später im Rahmen des elektronischen Versands übermittelt werden.

  5. Versand-Codeunit-ID: Hier wird die Codeunit eingetragen, die den Versand der im Buffer gespeicherten Belegdaten übernimmt.

Im Folgenden werden wichtige Codeunits erläutert:

Codeunit-ID

Codeunit-Beschriftung

Erläuterung

5518587

BRAG eDoc Buff.Export Endp.

Wird im Exportprozess eingesetzt. Sobald ein Beleg im System zur Übermittlung freigegeben wird, sammelt die CU die relevanten Daten. Dieser Zwischenspeicher wird dann an die nächste CU 5518588 weitergegeben, die den eigentlichen Versand übernimmt.

5518588

BRAG eDoc Buff.Delivery EndP.

Diese CU übernimmt die eigentliche Übermittlung. Sie verarbeitet die im Export-Buffer gespeicherten Belegdaten und stellt sicher, dass die Daten sicher an den Empfänger (z. B. Clearingstelle) versendet werden.

1610

Exp. Sales Inv. PEPPOL BIS3.0

Exportiert Verkaufsrechnungen gemäß PEPPOL BIS3.0-Standard. Diese Codeunit erstellt eine konforme XML-Datei für elektronische Rechnungen, die über das PEPPOL-Netzwerk gesendet werden können.

1611

Exp. Sales CrM. PEPPOL BIS3.0

Exportiert Verkaufsgutschriften (Credit Memos) gemäß PEPPOL BIS3.0-Standard. Diese Codeunit verarbeitet Gutschriften und generiert ein PEPPOL-konformes Dokument.

1612

Exp. Serv.Inv. PEPPOL BIS3.0

Exportiert Dienstleistungsrechnungen gemäß PEPPOL BIS3.0-Standard. Wird für die Erstellung von Rechnungen im Dienstleistungsbereich verwendet.

1613

Exp. Serv.CrM. PEPPOL BIS3.0

Exportiert Dienstleistungsgutschriften (Credit Memos) gemäß PEPPOL BIS3.0-Standard. Ähnlich wie bei Verkaufsdokumenten, aber für Dienstleistungen.

1620

PEPPOL Validation

Führt eine Validierung von PEPPOL-Dokumenten durch, um sicherzustellen, dass sie den BIS3.0-Standards entsprechen. Dies stellt sicher, dass die XML-Dokumente korrekt strukturiert sind und alle notwendigen Daten enthalten.

1621

PEPPOL Service Validation

Führt zusätzliche Validierungen auf der Dienstleistungsebene durch, um die Konformität von PEPPOL-Dokumenten im Bereich Dienstleistungen zu gewährleisten. Sie prüft auf servicespezifische Anforderungen.

Codeunit 5518587 BRAG eDoc Buff.Export Endp. und 5518588 BRAG eDoc Buff.Delivery EndP. werden immer in Kombination verwendet.

Belegsendeprofile

Sie ist eine Konfiguration, die festlegt, auf welchem Weg und in welchem Format Belege wie Rechnungen, Gutschriften und weitere mehr an Empfänger gesendet werden. Dies betrifft sowohl den Versand per E-Mail als auch über andere elektronische Wege wie das eDoc-Format.

eDoc Endpunkte

Ist ein definierter technischer Schnittstellenpunkt, über den elektronische Dokumente (eDocs) exportiert oder importiert werden. Diese Schnittstelle fungiert als "Brücke" zwischen dem ERP-System und externen Systemen, wie z. B. Kundensystemen, Behörden, Clearingstellen oder Drittanbietern. Der eDoc Endpunkt verarbeitet dabei den Transfer von Belegen.

Folgende Felder werden nun näher beschrieben:

  1. Code: Wird im eDoc Kundenendpunkt angewendet. Er definiert in Kombination mit dem eDoc Profil und eventuell einem spezifischen Debitor, welcher Endpunkt verwendet wird.

  2. Beschreibung:

  3. Aktiv: Gibt an, ob der eDoc Endpunkt aktiv ist. Bei true ist der Endpunkt aktiv und nutzbar, bei false ist er deaktiviert.

  4. eDoc Endpunkt: Der Name des Endpunkts, der den Typ des Formats beschreibt.

  5. Endpunkt: Die URL des eDoc Endpunkts, über die die Belege elektronisch gesendet/empfangen werden. Dies kann eine Webservice- oder API-URL sein.

  6. Authentifizierungsart: Legt fest, mit welcher Authentifizierungsmethode auf den Endpunkt zugegriffen wird. Die verfügbaren Authentifizierungsarten werden im Abschnitt Genauere Erläuterung beschrieben.

  7. Anzahl der Auth.-Parameter: Anzahl der Parameter, die für die Authentifizierung benötigt werden, variiert je nach Authentifizierungsart.

  8. Anzahl URL-Parameter: Anzahl der Parameter, die in der URL übergeben werden müssen, variiert je nach Authentifizierungsart.

  9. Anzahl HTTP-Header-Parameter: Anzahl der HTTP-Header-Parameter, die je nach Authentifizierungsart benötigt werden.

  10. Letzte eingehende Übertragung: Datum der letzten erfolgreichen Übertragung, die über diesen Endpunkt empfangen wurde. Dient zur Überwachung der Systemaktivität.

Genauere Erläuterung

Authentifizierungsart: Über das Feld Authentifizierungsart wird festgelegt, wie sich der eDoc Endpunkt gegenüber dem angebundenen externen System authentifiziert. Abhängig von der gewählten Authentifizierungsart werden unterschiedliche Parameter benötigt und bei der Kommunikation mit dem Endpunkt unterschiedlich verarbeitet.

Authentifizierungsart

Beschreibung

Basic

Verwendet die klassische HTTP-Basic-Authentifizierung. Benutzername und Passwort werden für die Authentifizierung verwendet und im HTTP-Authorization-Header übertragen.

APIKey500

Authentifizierung über einen API-Key mit einer vorgesehenen maximalen Länge von 500 Zeichen. Wird für Schnittstellen verwendet, die einen API-Key zur Identifikation und Authentifizierung erwarten.

APIKey1000

Entspricht grundsätzlich APIKey500, erlaubt jedoch einen längeren API-Key mit bis zu 1000 Zeichen. Welche Variante verwendet wird, hängt von der Länge bzw. den Anforderungen des angebundenen Systems ab.

RefreshToken

Tokenbasierte Authentifizierung mit einem Refresh Token. Das Refresh Token wird verwendet, um ein neues bzw. aktualisiertes Access Token für API-Aufrufe zu erhalten. Dadurch müssen Zugangsdaten nicht bei jedem Ablauf eines Access Tokens erneut eingegeben werden.

HeaderKey

Die Authentifizierungsinformation wird über einen definierten HTTP-Header an den Endpunkt übertragen. Diese Variante wird für APIs verwendet, die beispielsweise einen eigenen API-Key-Header anstelle des standardmäßigen Authorization-Headers erwarten.

OAuth 2.0

Verwendet das standardisierte OAuth-2.0-Verfahren. Dabei wird ein Access Token bezogen und anschließend für die Authentifizierung der API-Aufrufe verwendet. Die dafür benötigten Parameter hängen vom jeweiligen OAuth-Provider und dem verwendeten Flow ab.

Bearer Token by Refresh Token

Verwendet ein Refresh Token, um einen gültigen Bearer-/Access-Token abzurufen bzw. zu erneuern. Der erhaltene Token wird anschließend als Authorization: Bearer <Token> an den eigentlichen eDoc Endpunkt übertragen.

ApiKey

Allgemeine API-Key-Authentifizierung. Der API-Key wird entsprechend der Konfiguration des Endpunkts für die Authentifizierung verwendet. Diese Variante wird beispielsweise bei APIs eingesetzt, die einen festen API-Key erwarten.

Bearer Token by Credentials

Ein Bearer-/Access-Token wird anhand hinterlegter Zugangsdaten angefordert. Der erhaltene Token wird anschließend als Bearer Token für die Kommunikation mit dem eigentlichen eDoc Endpunkt verwendet.

Die Authentifizierungsarten unterscheiden sich insbesondere darin, wie die Zugangsdaten bereitgestellt werden und ob vor dem eigentlichen API-Aufruf zunächst ein Token abgerufen werden muss.

Bei Basic, ApiKey, APIKey500, APIKey1000 und HeaderKey können die hinterlegten Authentifizierungsinformationen direkt für den Request verwendet werden. Bei den tokenbasierten Varianten wie OAuth 2.0, RefreshToken, Bearer Token by Refresh Token und Bearer Token by Credentials kann dagegen zunächst ein Access- bzw. Bearer-Token ermittelt oder erneuert werden, der anschließend für den eigentlichen Request verwendet wird.

Die für eine Authentifizierungsart erforderlichen Werte werden über die zugehörigen Authentifizierungsparameter des eDoc Endpunkts gepflegt. Die benötigte Anzahl und Bedeutung dieser Parameter hängt von der jeweiligen Authentifizierungsart und dem angebundenen externen System ab.

Beispiel Billit: Für den Billit-Endpunkt wird die Authentifizierungsart ApiKey verwendet. Der von Billit bereitgestellte API-Key wird als Authentifizierungsparameter hinterlegt. Zusätzlich werden die für Billit benötigten HTTP-Header und der ProfilType CustomJson konfiguriert.

Anzahl Parameter: Je nach Authentifizierungsart kann sich die Anzahl der Parameter in der URL, in den HTTP-Headern oder zur Authentifizierung ändern.

eDoc Kundenendpunkte

Sie ist eine wichtige Konfiguration, die es ermöglicht, elektronische Dokumente gezielt an Debitoren zu senden. Kundenendpunkte definieren, welcher Kunde mit welchem eDoc Endpunkt und eDoc Profil verbunden ist, um den Austausch von Dokumenten in elektronischem Format zu steuern.

Der Kundenendpunkt beschreibt die Verbindung eines bestimmten Kunden oder einer Gruppe von Kunden mit einem spezifischen eDoc Endpunkt und einem eDoc Profil. Über diese Konfiguration wird festgelegt, über welchen Endpunkt und in welchem Format elektronische Belege an einen Kunden gesendet werden.

Felder des Kundenendpunkts:

Kunden-ID: Optionales Feld zur Angabe eines spezifischen Kunden. Wird dieses Feld nicht ausgefüllt, gilt die Konfiguration für alle Debitoren.

Profil Code: Definiert den Typ des zu übermittelnden eDocs. Dieses Profil bestimmt das Format und die Struktur des Belegs.

Endpunkt: Wird verwendet, um den Beleg zu übermitteln. Der Endpunkt enthält die URL und andere technische Details, die den Versand steuern.

Datensatz-Exportpuffer

Weitere Infos finden Sie unter: brAG eDoc App

Last updated: