Check identifier 66666 — APERAK
Check identifier 66666 · EDIFACT message type APERAK · format version 202604
Data structure
| Structure (BO4E) | Description | Format | 66666 | Condition |
|---|---|---|---|---|
| stammdaten * | — | object | Must | — |
| STATUSBERICHT [ ] * | — | object[] | Must | — |
| datumPruefung *00010 | Check date (when the item under check was checked) | string (date-time) | Must | — |
| pruefgegenstand *00020 | The checked document, e.g. the reference to the EDIFACT message that was checked / objected to | string | Must | — |
| transaktionsdaten * | — | object | Must | — |
| dokumentennummer *00030 | EDIFACT reference from the BGM segment / BGM | string | Must | — |
| kategorie *00040 | Qualifier from the beginning of the EDIFACT message / BGM | string | Must | — |
| nachrichtendatum *00050 | Creation date of the EDIFact / DTM+137 | string (date-time) | Must | — |
| nachrichtenreferenznummer *00060 | EDIFACT reference from the UNT segment / UTILMD UNT+21 | string | Must | — |
| absender * | — | object | Must | — |
| rollencodenummer *00070 | Specifies the code value of the market role. | string | Must | — |
| rollencodetyp *00080 | Indicates the type of the code. | Enum Rollencodetyp | Must | — |
BDEW | — | — | Must | — |
GS1 | — | — | Must | — |
GLN | — | — | Must | — |
DVGW | — | — | Must | — |
| ansprechpartner | — | object | May | — |
| eMailAdresse00090 | Email address | string | May | — |
| nachname00100 | Surname (family name) of the contact person | string | May | — |
| rufnummern [ ] | — | object[] | May | — |
| nummerntyp00110 | Phone number type | Enum Rufnummernart | May | — |
RUF_ZENTRALE | — | — | May | — |
FAX_ZENTRALE | — | — | May | — |
SAMMELRUF | — | — | May | — |
SAMMELFAX | — | — | May | — |
ABTEILUNGRUF | — | — | May | — |
ABTEILUNGFAX | — | — | May | — |
RUF_DURCHWAHL | — | — | May | — |
FAX_DURCHWAHL | — | — | May | — |
MOBIL_NUMMER | — | — | May | — |
| rufnummer00120 | rufnummer | string | May | — |
| empfaenger * | — | object | Must | — |
| rollencodenummer *00130 | Specifies the code value of the market role. | string | Must | — |
| rollencodetyp *00140 | Indicates the type of the code. | Enum Rollencodetyp | Must | — |
BDEW | — | — | Must | — |
GS1 | — | — | Must | — |
GLN | — | — | Must | — |
DVGW | — | — | Must | — |
Belongs to these role views
There is no role view for this check identifier: in this format version no process step of any market role carries it. A role statement would stand here without evidence.
No process in this release
The entry in which this check identifier appears is not a process but a chapter reference: as parties involved, the source names only running text there (“parties involved as in the original message”), and the step has neither a number nor an action. Counted as a process, it would have reported a coverage gap that is none — it still cannot be rendered. This is a gap in the process source, not in the delivery — and it is the reason why no “Belongs to these role views” table appears here.
No process assignment available
For PI_66666, no entry exists in any of the evaluated BDEW tables. Regulatory determination, process step and communication direction can therefore not be stated.
Transaction and responses
Role of this check identifier: response message. Basis: the message type. An APERAK is an acknowledgement (BGM 312) or an application error message (BGM 313) about a received message and cites it via RFF+ACE (number of the related document), RFF+AGO (sender's reference of the original message) and RFF+TN (transaction number of the referenced transaction) — as in the APERAK application handbook from 202610; the file of format version 202604 has no lines. The check identifier table gives it neither a title nor an action.
Responses: No response of this format version names this check identifier as a reference — neither explicitly in the Prüfi table nor via the step sequence. That does not mean there is none; it means that the sources do not record one.
These check identifiers are in the handbook with the same row structure. This is a unit of presentation and not a unit of transaction: which of them answers which is not stated by the group — that is above under »Request and response«.
| Check identifier | Use case | Message type |
|---|---|---|
| 99999 | — | APERAK |
Editorial — not derived from a source
How the APERAK cites the checked message, in the JSON. In the test case Z10_Testfall1 the back references are in these fields: RFF+ACE (number of the related document) in STATUSBERICHT.pruefgegenstand, RFF+ACW (reference number of a previous message) in fehler.fehlerDetails → ursache.dokument, RFF+AGO (sender's reference of the original message, the document number of your message) in ursache.nachricht and RFF+TN (transaction number of the referenced transaction) in ursache.transaktion. The APERAK's own interchange reference is in transaktionsdaten.datenaustauschreferenz.
Source: Test set maco-edi-testfiles, inbound/v202404/APERAK/Z10_Testfall1_eingehend (EDIFACT and JSON of the same test case, compared on 23.09.2026); application handbook APERAK 202610 (Knowledge Collection ahb/202610/APERAK) · As of: 2026-09-23 · Applies to format version: 202604, 202610 · To be reviewed by: 2027-04-01
Notes on this page
An * after a field or group name marks a mandatory field or a mandatory group. The type is beside it; where the value ends up in the EDIFACT segment is shown by the info icon next to the field name.
The status column carries two vocabularies because the manual answers two questions: on a group row, Muss, Soll or Kann states whether the EDIFACT segment must be present; on a field row, X states that this qualifier is used in this check identifier. Both are kept exactly as the source records them.
For this check identifier, the application handbook of this format version lists no row. The file exists and is empty — that is something other than a missing source, and is therefore presented differently.
No test case exists for this check identifier in the test data of the format version. There is therefore no example message here — not even a reconstructed one: on a page that promises evidence, an invented message would be worse than none.