This is a convenience translation. Only the German version is legally binding; in case of any discrepancy the German version prevails.
This Service Description states what the Software does, what the Provider delivers for the fixed price and what the Customer provides. Anything not stated here is not owed (License Agreement § 10 (4)).
1. Overview
edi-service.eu is an EDI hub that runs on the Customer's own Debian server. It exchanges orders, delivery schedules, despatch advices, invoices and other business messages between the Customer's ERP system and its trading partners, in both directions. An AI sets up the platform based on the trading partners' documents, creates mappings and the ERP connection and tests everything in TEST operation before the Customer approves production. The Software processes ongoing message traffic on a rule basis, without AI.
2. Formats
| Format | Scope |
|---|---|
| UN/EDIFACT | all message types and subsets via mappings (for example ORDERS, ORDCHG, ORDRSP, DELFOR, DESADV, INVOIC, also EANCOM); with and without UNA, several interchanges (UNB) and messages (UNH) per file; envelope validation |
| VDA | fixed-length format with 128 characters per record, among others VDA 4905, 4906 and 4913; also in EBCDIC encoding; record layout stored as data |
| CSV | freely definable structure per partner (delimiter, header line, columns) |
| JSON | freely definable structure per partner |
| XML | freely definable structure per partner, without DTD and external entities |
All formats are translated into and generated from a uniform, versioned canonical format. Further formats can be added as data; they become part of the contract with the Service Description of a later version.
3. Message types and directions
- Inbound direction (partner to ERP): order, order change, delivery schedule, forecast, Kanban.
- Outbound direction (ERP to partner): order response, despatch advice, invoice and order to suppliers. The Software assigns the required number ranges (for example interchange and message references) and processes the technical acknowledgments of the other side.
- Any number of message types in both directions is possible per trading partner.
4. Transport channels
| Channel | Inbound | Outbound | Notes |
|---|---|---|---|
| AS2 | yes | yes | signed and encrypted as agreed with the partner, receipt acknowledgment (MDN) |
| OFTP2 | yes | yes | over TCP and TLS, receipt acknowledgment (EERP); identifiers based on Odette ID |
| SFTP | yes | yes | isolated per partner |
| HTTPS | yes | yes | inbound via a dedicated endpoint per channel that is publicly reachable only for deliveries, with a token per channel; outbound to the partner's address |
| yes | yes | collection from a mailbox of the Customer, sending via the Customer's mail server | |
| Folder | yes | yes | storage on the server, for example for partner or ERP systems in the Customer's own network |
- All channels use the same processing path: receipt, storage of the original, recognition, mapping, handover.
- The transport components for AS2 and OFTP2 run in their own containers on the Customer's server (License Agreement § 7). The OFTP2 component is not tested by Odette. If a trading partner requires Odette-tested software, the Provider points this out before the contract is concluded.
- For HTTPS inbound, the Customer stores its own TLS certificate. Without a certificate, the Software generates a self-signed one in TEST operation only; in production, the inbound channel then remains closed.
- The server's firewall opens incoming ports only for configured inbound channels.
5. ERP connection
| Adapter | Scope |
|---|---|
| REST and webhook | handover to and retrieval from an HTTP interface of the ERP, authentication via a header with a key, acknowledgment by the ERP |
| Interface tables | handover via tables in a database of the ERP (staging) |
| File | handover of CSV, XML or JSON files via folder, SFTP or Windows share (SMB), with acknowledgment |
- The fixed price includes the connection to one ERP system via one of these standard adapters, in each case with a TEST target and a PROD target.
- Handover runs via a queue with retry on errors, idempotency and duplicate detection. A message is not handed over to the ERP twice.
- Adaptations and programming in the ERP itself are not included (License Agreement § 10 (4)).
6. Setup
- Onboarding: The Customer uploads its trading partners' documents (EDI guideline, cover letter, sample files). From these, the AI reads message types, formats, versions, transport channel, identifiers and test procedure and shows the result for confirmation. A few questions follow. Different persons can answer functional and technical questions via separate links. The result is the implementation specification.
- Check script and installation: Before the installation, a check script shows whether the server meets the requirements under section 10. The Customer starts the installation itself with a single-use command. The installation is versioned and repeatable.
- Setup by the AI: From the specification, the setup agent creates partners, channels, identifiers, mappings and ERP targets, checks the mappings against the sample messages and reports the result. Missing information becomes follow-up questions in the dashboard. Everything is created in TEST operation first.
- Approval: An administrator of the Customer switches production on, in two steps and logged.
- New partners, new message types and mapping changes follow the same path, within the scope of License Agreement § 10.
7. Dashboard and configuration API
- Dashboard in the browser (German and English) with - overview of messages, processing status and alerts with the affected original line, - partners, channels, identifiers, mappings with versions and test cases, ERP targets and settings, - follow-up questions and proposals of the AI with approval, - change log with originator, old value and new value, - license status (edition, expiry, grace period), - export of the entire configuration (License Agreement § 8 (4)).
- Users and roles: login with roles; critical actions (switching to production, certificates, credentials, deletion, activating partners) require a renewed login.
- Credentials (partners, ERP, AI key) are stored encrypted on the server. They can be set, replaced and tested, but not read in plain text.
- Configuration API (versioned, with OpenAPI description): the dashboard, the AI and the Customer's own tools use the same interface. The AI accesses it via an MCP server with its own token and defined permissions; it can only propose critical actions.
- Archive: Every inbound and outbound message is retained in its original form.
8. Monitoring and alerts
- Alerts: Errors in receipt, processing or handover appear in the dashboard and are sent as a digest email to the configured recipients.
- Certificate monitoring: The dashboard shows the remaining validity of all certificates (partners, AS2, OFTP2, HTTPS inbound). The Instance warns 60, 30 and 7 days before expiry.
- AI consumption: The dashboard shows AI consumption (tokens and costs according to the AI provider's price list) per setup, per partner connection and per mapping change. A cost budget applies to each setup job.
- The Provider does not actively monitor the Instance (SLA section 7).
9. Updates and support
- Updates of the Software are included in the price. The Instance fetches them itself, verifies the signature and applies them locally; the Customer can pause them (SLA section 5, License Agreement § 11).
- Support in German and English in accordance with the SLA.
- Customer portal at app.edi-service.eu: license status, contract, billing interval, contact persons, onboarding links, installation token and termination.
10. What the Customer provides
| Area | Requirement |
|---|---|
| Server | own server or own virtual machine with Debian 13 (amd64), used only for edi-service.eu; for production at least 8 GB of RAM, 2 CPU cores (4 recommended) and 40 GB of free storage; time synchronization and working name resolution |
| Network | outbound: app.edi-service.eu, package repositories, container registries, AI provider, partner connections; inbound only for the channels used (for example 443 for HTTPS and AS2, 6619 for OFTP2) with a public name and port forwarding |
| AI | own contract with an AI provider for a model on the current minimum list (License Agreement § 9) |
| ERP | interface according to section 5 and a test environment or test client |
| Documents | EDI guidelines, sample files and identifiers of the trading partners |
| Persons | one functional and one technical contact person for questions, tests with the partner and approval |
| Backup | regular backup according to section 11 |
11. Backup requirements for the Customer
| Path | back up? | Note |
|---|---|---|
/var/lib/edi-service/postgres, /var/lib/edi-service/data |
yes | configuration, messages, archive; back up the database consistently (export or stopped service) |
/etc/edi-service |
yes, encrypted and stored separately | keys of the Instance and of the credentials |
/var/lib/edi-service/edge |
no | is regenerated from the database and contains the private TLS key of the HTTPS inbound channel; marked with CACHEDIR.TAG |
The Customer tests the restore at least once after the setup.
12. Not included
- X.400 and VAN mailboxes,
- a web EDI portal for partners without EDI,
- Peppol access,
- Odette-tested OFTP2 software,
- high availability (standby server) and round-the-clock support,
- operation, backup and operating system updates of the server,
- adaptations in the ERP system itself,
- legal and tax advice, for example on e-invoicing.