Endpoint Management
Electronic Document Format
It is used for the electronic transmission and processing of sales and service invoices as well as sales and service credit memos. This documentation explains its use in the document sending profile as well as the relevant technical components for export and dispatch processing via codeunits.
The following goes into more detail about the fields in the Electronic Document Format:
-
Code: It is entered in the document sending profile in the "Format" field. This code indicates which format is used to transmit the document.
-
Description:
-
Usage: The entry is important to correctly categorize and process the documents.
-
Codeunit ID: Here the codeunit is entered, which depending on the codeunit serves to store and process data that will later be transmitted as part of the electronic dispatch.
-
Delivery Codeunit ID: Here the codeunit is entered that takes over the sending of the document data stored in the buffer.
Important codeunits are explained below:
|
Codeunit ID |
Codeunit Label |
Explanation |
|---|---|---|
|
5518587 |
BRAG eDoc Buff.Export Endp. |
Used in the export process. As soon as a document in the system is released for transmission, the CU collects the relevant data. This intermediate buffer is then passed to the next CU 5518588, which takes over the actual delivery. |
|
5518588 |
BRAG eDoc Buff.Delivery EndP. |
This CU takes over the actual transmission. It processes the document data stored in the export buffer and ensures that the data is securely sent to the recipient (e.g., clearing house). |
|
1610 |
Exp. Sales Inv. PEPPOL BIS3.0 |
Exports sales invoices according to the PEPPOL BIS3.0 standard. This codeunit creates a compliant XML file for electronic invoices that can be sent via the PEPPOL network. |
|
1611 |
Exp. Sales CrM. PEPPOL BIS3.0 |
Exports sales credit memos (Credit Memos) according to the PEPPOL BIS3.0 standard. This codeunit processes credit memos and generates a PEPPOL-compliant document. |
|
1612 |
Exp. Serv.Inv. PEPPOL BIS3.0 |
Exports service invoices according to the PEPPOL BIS3.0 standard. Used for creating invoices in the services area. |
|
1613 |
Exp. Serv.CrM. PEPPOL BIS3.0 |
Exports service credit memos (Credit Memos) according to the PEPPOL BIS3.0 standard. Similar to sales documents but for services. |
|
1620 |
PEPPOL Validation |
Performs validation of PEPPOL documents to ensure they comply with BIS3.0 standards. This ensures that the XML documents are correctly structured and contain all necessary data. |
|
1621 |
PEPPOL Service Validation |
Performs additional validations at the service level to ensure the compliance of PEPPOL documents in the services area. It checks for service-specific requirements. |
Codeunit 5518587 BRAG eDoc Buff.Export Endp. and 5518588 BRAG eDoc Buff.Delivery EndP. are always used in combination.
Document Sending Profiles
It is a configuration that determines by which route and in which format documents such as invoices, credit memos and others are sent to recipients. This concerns both sending by e-mail and other electronic means such as the eDoc format.
eDoc Endpoints
Is a defined technical interface point through which electronic documents (eDocs) are exported or imported. This interface acts as a "bridge" between the ERP system and external systems, such as customer systems, authorities, clearing houses or third parties. The eDoc endpoint handles the transfer of documents.
The following fields are now described in more detail:
-
Code: Is applied in the eDoc customer endpoint. In combination with the eDoc profile and possibly a specific customer, it defines which endpoint is used.
-
Description:
-
Active: Indicates whether the eDoc endpoint is active. If true the endpoint is active and usable, if false it is deactivated.
-
eDoc Endpoint: The name of the endpoint that describes the type of the format.
-
Endpoint: The URL of the eDoc endpoint through which documents are electronically sent/received. This can be a web service or API URL.
-
Authentication Type: Determines which authentication method is used to access the endpoint. The available authentication types are described in the Detailed Explanation section.
-
Number of Auth. Parameters: Number of parameters required for authentication, varies depending on the authentication type.
-
Number of URL Parameters: Number of parameters that must be passed in the URL, varies depending on the authentication type.
-
Number of HTTP Header Parameters: Number of HTTP header parameters required depending on the authentication type.
-
Last Incoming Transmission: Date of the last successful transmission received via this endpoint. Used to monitor system activity.
Detailed Explanation
Authentication Type: The Authentication Type field determines how the eDoc endpoint authenticates itself to the connected external system. Depending on the chosen authentication type, different parameters are required and processed differently when communicating with the endpoint.
|
Authentication Type |
Description |
|---|---|
|
Basic |
Uses classic HTTP Basic authentication. Username and password are used for authentication and transmitted in the HTTP |
|
APIKey500 |
Authentication via an API key with a designated maximum length of 500 characters. Used for interfaces that expect an API key for identification and authentication. |
|
APIKey1000 |
Essentially corresponds to |
|
RefreshToken |
Token-based authentication with a refresh token. The refresh token is used to obtain a new or updated access token for API calls. This means credentials do not have to be re-entered every time an access token expires. |
|
HeaderKey |
The authentication information is transmitted to the endpoint via a defined HTTP header. This variant is used for APIs that, for example, expect their own API key header instead of the standard |
|
OAuth 2.0 |
Uses the standardized OAuth 2.0 procedure. An access token is obtained and then used for authenticating API calls. The parameters required for this depend on the respective OAuth provider and the flow used. |
|
Bearer Token by Refresh Token |
Uses a refresh token to retrieve or renew a valid bearer/access token. The received token is then transmitted as |
|
ApiKey |
General API key authentication. The API key is used for authentication according to the endpoint configuration. This variant is used, for example, with APIs that expect a fixed API key. |
|
Bearer Token by Credentials |
A bearer/access token is requested based on stored credentials. The received token is then used as a bearer token for communication with the actual eDoc endpoint. |
The authentication types differ in particular in how the credentials are provided and whether a token must first be retrieved before the actual API call.
For Basic, ApiKey, APIKey500, APIKey1000 and HeaderKey the stored authentication information can be used directly for the request. For token-based variants like OAuth 2.0, RefreshToken, Bearer Token by Refresh Token and Bearer Token by Credentials, an access or bearer token can first be obtained or renewed, which is then used for the actual request.
The values required for an authentication type are maintained via the associated authentication parameters of the eDoc endpoint. The number and meaning of these parameters depend on the respective authentication type and the connected external system.
Example Billit: For the Billit endpoint the authentication type ApiKey is used. The API key provided by Billit is stored as an authentication parameter. In addition, the HTTP headers required for Billit and the ProfileType CustomJson are configured.
Number of Parameters: Depending on the authentication type, the number of parameters in the URL, in the HTTP headers or for authentication may change.
eDoc Customer Endpoints
It is an important configuration that makes it possible to send electronic documents specifically to customers. Customer endpoints define which customer is connected with which eDoc endpoint and eDoc profile to control the exchange of documents in electronic format.
The customer endpoint describes the connection of a specific customer or a group of customers with a specific eDoc endpoint and an eDoc profile. Through this configuration it is determined through which endpoint and in which format electronic documents are sent to a customer.
Fields of the customer endpoint:
Customer ID: Optional field to specify a specific customer. If this field is not filled, the configuration applies to all debtors.
Profile Code: Defines the type of eDoc to be transmitted. This profile determines the format and structure of the document.
Endpoint: Used to transmit the document. The endpoint contains the URL and other technical details that control the dispatch.
Record Export Buffer
For more information see: brAG eDoc App