EDI and abas Part 1: Architecture, EDP/FOP Interface, and abas-to-EDIFACT Conversion Rules

abas ERP is one of the most widely adopted enterprise resource planning systems among mid-sized manufacturing, automotive Tier-1/Tier-2, metalworking, plastics, and wholesale distribution companies in Central Europe. However, their external trading partners—international automotive OEMs, retail and DIY chains, and logistics providers—do not exchange data in native abas structures. Instead, they require standardized UN/EDIFACT messages (typically the EANCOM subset in retail and ODETTE/VDA-derived EDIFACT subsets in the automotive sector). In this four-part series, we explore the technical rules of abas-to-EDIFACT conversion, interface architecture, and the most frequent real-world operational pitfalls.

This first installment establishes the architectural foundation: how data flows between abas ERP (Vartab, EDP, FOP/EFOP, and the abas EDI interface) and an external EDI translator, the core syntactic and structural rules of the EDIFACT envelope, and why integration projects often stumble on their very first message.

The Real-World Scenario Across This Series

To illustrate conversion rules in a realistic industrial context, all four parts follow a practical mid-market manufacturing scenario:

• Pannon Auto Parts Ltd. – A mid-sized metal and plastics manufacturer running abas ERP. This represents our internal ERP environment (GLN: 5990000000108).
• EuroAuto Tier-1 GmbH – A German automotive systems buyer sending UN/EDIFACT D.96A / D.07A scheduling agreements and JIT call-offs (DELFOR, DELJIT) and requiring strictly structured despatch advices (DESADV) and invoices (INVOIC) (GLN: 4012345000016).
• DIY Retail Chain Corp. – A national retail chain sending discrete purchase orders via EANCOM D.96A (ORDERS) for delivery to its central distribution center (GLN: 5990000000207, DC GLN: 5990000000214), expecting ORDRSP, DESADV, and INVOIC messages in return.

Our sample product is a stamped brake bracket assembly: its internal abas ID number (nummer) is A-40210, search word (such) is FEKKONZOL-40, GTIN is 5991234004023, and EuroAuto's buyer part number is EA-99812-B.

How Does Data Flow In and Out of abas ERP?

abas ERP is built on an object-oriented database architecture centered around the Vartab (variable table). Every master data record (customer, part, packaging material) and every transaction document (sales order, blanket order/release, packing slip, invoice) consists of Header (Head) and Table (row) fields addressable via German or English variable names, extensible with custom y... user fields.

Rather than generating raw EDIFACT character streams directly inside screen masks, enterprise abas environments rely on a two-tier integration architecture dividing responsibilities between the internal abas interface and an external EDI converter (middleware):

1. Internal abas EDI Interface & FOP/EFOP Event Handling: When a business document (such as a packing slip or invoice) is released in abas, an FOP (Flexible Oberflächenprogrammierung) script or Java-based EFOP event handler validates business prerequisites and triggers the abas EDI module (or a dedicated export Infosystem) to output a structured intermediate payload (XML, flat file, or JSON).
2. EDP (Electronic Data Processing) / REST API Interface: For inbound messages, the external middleware communicates via the abas EDP interface (or REST API / EDI staging tables) to create or update abas business objects—executing the exact same business logic and field-level validations as manual GUI entry.
3. EDI Translator (Middleware) & B2B Gateway: The converter handles secure B2B transport (AS2, OFTP2, SFTP), syntactic validation, structural mapping between EDIFACT segments and abas intermediate files, and technical acknowledgments (CONTRL).

The EDIFACT Envelope and Fundamental Conversion Rules

Whether exchanging EANCOM messages with a retail chain or automotive EDIFACT messages with an OEM, the outer interchange envelope follows strict syntactic rules:

UNA:+.? '
UNB+UNOD:3+5990000000207:14+5990000000108:14+261021:0830+00000451++ORDERS'
UNH+1+ORDERS:D:96A:UN:EAN008'
BGM+220+BL-2026-88412+9'
DTM+137:20261021:102'
...
UNT+18+1'
UNZ+1+00000451'

1. Delimiters and Character Escaping Rules

The UNA:+.? ' segment defines the five EDIFACT control characters: component separator (:), data element separator (+), decimal mark (.), release/escape character (?), and segment terminator ('). Text fields exported from abas (such as part descriptions or delivery remarks) frequently contain + or : characters (e.g., Bolt M8+Nut Ratio 1:2). Rule: abas exports should never strip these characters manually; the EDI translator must automatically prefix any control character with the ? release character (Bolt M8?+Nut Ratio 1?:2).

2. Decimal Notation and Numeric Formatting

In European abas locales, screens and reports often format decimals using a comma (12,50) and may include thousand separators. In EDIFACT (when character 4 of UNA is .), only the period is valid as a decimal mark, and thousand separators are strictly forbidden. Outbound EDP/Infosystem exports must always output machine-readable, locale-independent numeric values.

3. Separating Internal Keys from External EDI Identifiers

Every record in abas has an internal database object reference (e.g., (184,0,0)), an identity number (nummer, e.g., 70045), and a search word (such). External trading partners have no visibility into these internal keys. EDIFACT UNB and NAD segments must exclusively carry globally recognized or partner-assigned identifiers:

• In retail: the 13-digit GLN (qualifier 14 in UNB, ::9 in NAD);
• In automotive: DUNS numbers, ODETTE IDs, or buyer-assigned supplier codes (NAD+SU+987654::92).

Message Map for This 4-Part Series

Across the upcoming parts of this series, we examine the following core business processes and their abas ↔ EDIFACT mapping rules:

Acknowledgment Tiers: When Is a Message Truly Processed?

Reliable EDI operations require distinguishing between three separate acknowledgment layers:

1. Transport Receipt (AS2 MDN / OFTP2 EERP): Confirms only that the encrypted payload arrived intact at the remote server.
2. Syntactic Receipt (EDIFACT CONTRL): Generated by the receiving EDI translator to confirm adherence to EDIFACT syntax rules (UCI / UCM segments).
3. Application / ERP Level (APERAK or internal EDP status): Confirms whether the abas EDP interface actually booked the sales order or updated the blanket release. If a part is blocked in abas, CONTRL will still be positive while the EDP import fails!

Common Pitfalls in Practice

• Character Encoding Mismatches (UNOC vs. UNOD / UNOW): The default UNOC (ISO 8859-1) syntax identifier lacks Central European diacritics (such as Hungarian ő, ű or Polish/Czech/Croatian characters). Using UNOC instead of UNOD:3 (ISO 8859-2) or UNOW:4 (UTF-8) corrupts partner names and street addresses.
• Field Length Truncation and Multi-Byte Splitting: EDIFACT NAD name and street components are limited to 35 characters (an..35), whereas abas description and address fields can be longer. When converting UTF-8 strings, splitting must occur on character boundaries (never mid-byte) and overflow cleanly into subsequent C080/C059 sub-elements.
• Interactive FOP Dialogs Blocking Background EDP Jobs: A classic abas pitfall occurs when an existing screen FOP triggers a modal dialog (box or menu command) upon credit limit warnings or unit discrepancies. While a human user simply clicks "OK" in the GUI, an unattended EDP background session hangs or aborts. Rule: FOP scripts must always check execution mode and route warnings to log files or custom status fields (e.g., yedierr) during background EDI runs.
• Test vs. Production Environment Mix-ups: Element 0035 in the UNB segment flags test transmissions (1). Failing to filter this flag in the translator can route a buyer's test schedule directly into the live abas production client.

Summary

The flexible Vartab and FOP/EDP architecture of abas ERP provides a strong foundation for automated B2B data exchange, provided that external EDIFACT translation and internal ERP validation are cleanly decoupled. The converter handles syntax, character encodings, and identifier mapping, while abas FOP logic must be engineered for headless, unattended execution.

In Part 2 of this series, we examine inbound demand flows: converting EANCOM ORDERS into abas sales orders with ORDRSP confirmations, and managing cumulative quantities (FZ numbers) in automotive DELFOR and DELJIT releases.

Planning an abas ERP EDI integration or auditing your existing converter rules? Request a free consultation or test your EDIFACT files with our online EDIFACT Validator.