972-836-7750 Request a demo Talk to an expert
Talk to an expert Request a demo Call sales 972-836-7750

EDIFACT message guide · Master data

DMRDEF Data maintenance request definition

The UN/EDIFACT message that transfers a data maintenance request, a proposed change to the directories, among the parties that process it.

Sent by
Submitter or standards working group
Received by
Parties that assess and process directory changes
Standard
UN/EDIFACT · Batch message
X12 equivalent
No direct equivalent

What is the EDIFACT DMRDEF message?

DMRDEF is the UN/EDIFACT data maintenance request definition message. The directory defines it as a message that transfers a data maintenance request (DMR) action among the parties involved in preparing, processing, assessing and resolving requests and producing the directories.

Changes to UN/EDIFACT, such as new code values, segments or messages, start as data maintenance requests. DMRDEF carries the request itself in structured form, and its status is tracked with DMSTAT through to publication in a new directory release. It is used within the UN/CEFACT process.

How the EDIFACT DMRDEF message worksDiagram of the UN/EDIFACT DMRDEF Data maintenance request definition message. Submitter or standards working group sends it to parties that assess and process directory changes. It usually starts the exchange. It is usually followed by DMSTAT. Inside the UNB and UNH envelopes, the directory D.21A requires, in the start of message: BGM (Beginning of message), DII (Directory identification), DTM (Date/time/period) and FTX (Free text) and body and segment groups: the required SG1 loop with PNA (Party identification) and the required SG3 loop with MSG (Message type identification). 7 conditional segment groups are listed by their trigger segment.How the EDIFACT DMRDEF message worksData maintenance request definition: who sends it, where it fits and what the directory marks mandatory1 WHERE IT FITSUSUALLY FOLLOWSStarts the exchangeDMRDEFSENDERSubmitter or standardsworking groupRECEIVERParties that assessand process directorychangesCONTRL syntax report back, if agreedUSUALLY FOLLOWED BYDMSTATData maintenancestatus report/query2 WHAT DIRECTORY D.21A REQUIRESInterchange: sender and recipient IDsUNB … UNZMessage DMRDEFUNH … UNTSTART OF MESSAGEBGMBeginning of messageDIIDirectory identificationDTMDate/time/periodFTXFree textBODY AND SEGMENT GROUPSMandatory group SG1 · repeats up to 99PNAParty identificationMandatory group SG3 · repeats up to 1MSGMessage type identification+ 7 conditional groups, starting with:CTASGUFNTSEGCMPELMCDSBlue box: mandatory segment group. Conditional groups are listed by the trigger segment that starts them; a group is sent only when its data applies.Conditional segments outside groups are not drawn.Structure: mandatory segments and groups in the UN/EDIFACT directory D.21A listing for DMRDEF. Your trading partner's implementation guide adds itsown requirements.
How the EDIFACT DMRDEF message worksDiagram of the UN/EDIFACT DMRDEF Data maintenance request definition message. Submitter or standards working group sends it to parties that assess and process directory changes. It usually starts the exchange. It is usually followed by DMSTAT. Inside the UNB and UNH envelopes, the directory D.21A requires, in the start of message: BGM (Beginning of message), DII (Directory identification), DTM (Date/time/period) and FTX (Free text) and body and segment groups: the required SG1 loop with PNA (Party identification) and the required SG3 loop with MSG (Message type identification). 7 conditional segment groups are listed by their trigger segment.How the EDIFACT DMRDEFmessage worksData maintenance request definition: who sendsit, where it fits and what the directory marksmandatory1 WHERE IT FITSUSUALLY FOLLOWSStarts the exchangeDMRDEFSENDERSubmitter orstandardsworking groupRECEIVERParties thatassess andprocessdirectorychangesCONTRL syntax report back, if agreedUSUALLY FOLLOWED BYDMSTATData maintenance statusreport/query2 WHAT DIRECTORY D.21A REQUIRESInterchange: sender and recipient IDs(UNB … UNZ)Message DMRDEF (UNH … UNT)START OF MESSAGEBGMBeginning of messageDIIDirectory identificationDTMDate/time/periodFTXFree textBODY AND SEGMENT GROUPSMandatory group SG1 · repeats upto 99PNAParty identificationMandatory group SG3 · repeats upto 1MSGMessage type identification+ 7 conditional groups, starting with:CTASGUFNTSEGCMPELMCDSBlue box: mandatory segment group. Conditionalgroups are listed by the trigger segment thatstarts them; a group is sent only when its dataapplies. Conditional segments outside groups arenot drawn.Structure: mandatory segments and groups in theUN/EDIFACT directory D.21A listing for DMRDEF.Your trading partner's implementation guide adds itsown requirements.

How to read this diagram: the top row shows who sends DMRDEF, to whom, and which messages usually come before and after it. The lower part shows what the directory D.21A itself requires: the envelopes around DMRDEF and the segments and segment groups it marks mandatory. Conditional groups are listed by their trigger segment rather than drawn in full. This is the directory's minimum, not a trading partner's requirement: a message implementation guide, such as an industry subset or a partner’s own guide, usually makes some conditional groups mandatory, restricts the codes and may use an older directory.

Expand diagram Download SVG

When it is used

  • Submitting a request to change the directories
  • Passing requests between working groups
  • Recording resolved changes for directory production

Where it fits in the message flow

This message DMRDEF Data maintenance request definition
Usually followed by DMSTAT Data maintenance status report/query

Structure

Mandatory segments in DMRDEF (directory D.21A)

In UN/EDIFACT directory D.21A, the DMRDEF message has 52 segment positions arranged in 13 segment groups. These are the segments and segment groups marked mandatory at message level, in order; a mandatory group is shown with the segment that starts it. Segments inside conditional groups are needed only when the group is used. This is the directory’s requirement, not your trading partner’s: each partner’s message implementation guide names the directory it uses, often an older one such as D.96A or D.01B where the structure can differ, makes some conditional segments mandatory and restricts the codes.

  • UNH
  • BGM
  • DII
  • DTM
  • FTX
  • SG1 (PNA)
  • SG3 (MSG)
  • UNT

Practical example

DMRDEF in practice

An industry group needs a new code value for a transport event. Its standards representative prepares a data maintenance request with the proposed code, its description and justification, and submits it as a DMRDEF. The request is assessed by the responsible group and, once approved, appears in the next directory.

Implementation

Implementation considerations for DMRDEF

  • Follow UN/CEFACT procedures for data maintenance requests.
  • Justify changes with a business requirement.
  • Track the request through to the directory release.
  • Coordinate with the industry bodies that use the affected messages.

How ECOM helps

Automate DMRDEF with ECOM

Solution

EDI Integration

Exchange X12 and EDIFACT documents with partners and integrate them directly with your ERP.

Service

Mapping and Translation

Map development and maintenance for X12, EDIFACT, XML, JSON, flat files and ERP formats.

Solution

B2B Integration

Connect every customer, supplier, carrier and bank across EDI, API, file and portal channels.

Compare X12 and EDIFACT, or see answers to general questions in the EDI FAQ.

Related messages

Related master data messages

All 11 master data messages

Need help with DMRDEF?

ECOM maps, tests and monitors EDIFACT messages for your trading partners and integrates them with your ERP.

Request a Demo Contact us