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 · Travel and tourism

SKDUPD Schedule update

The UN/EDIFACT interactive message travel service providers use to send schedule information to other providers, agencies and publishers.

Sent by
Travel service provider, such as a rail or bus operator
Received by
Other providers, authorities or timetable publishers
Standard
UN/EDIFACT · Interactive (I-EDI) message
X12 equivalent
No direct equivalent

What is the EDIFACT SKDUPD message?

SKDUPD is the UN/EDIFACT schedule update message. The directory defines it as a message containing information about travel service schedules, sent by a travel service provider to other service providers or to agencies such as government departments, traffic authorities and timetable publishing companies.

Schedules describe services, their stops and times and the days they run. Publishing them electronically keeps journey planners, ticketing systems and partner operators in step when timetables change. Static data such as locations is sent separately with TSDUPD.

How the EDIFACT SKDUPD message worksDiagram of the UN/EDIFACT SKDUPD Schedule update message. Travel service provider, such as a rail or bus operator sends it to other providers, authorities or timetable publishers. It usually follows SKDREQ. Inside the UIB and UIH envelopes, the directory D.21A requires, in the start of message: MSD (Message action details), ORG (Originator of request details) and HDR (Header information) and body and segment groups: the required SG2 loop with PRD (Product identification). 3 conditional segment groups are listed by their trigger segment.How the EDIFACT SKDUPD message worksSchedule update: who sends it, where it fits and what the directory marks mandatory1 WHERE IT FITSUSUALLY FOLLOWSSKDREQSchedule requestSKDUPDSENDERTravel serviceprovider, such as a railor bus operatorRECEIVEROther providers,authorities ortimetable publishersUSUALLY FOLLOWED BYNo business reply expected2 WHAT DIRECTORY D.21A REQUIRESInteractive interchangeUIB … UIZMessage SKDUPDUIH … UITSTART OF MESSAGEMSDMessage action detailsORGOriginator of request detailsHDRHeader informationBODY AND SEGMENT GROUPSMandatory group SG2 · repeats many timesPRDProduct identification+ 3 conditional groups, starting with:ERISERPOPBlue 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 SKDUPD. Your trading partner's implementation guide adds itsown requirements.
How the EDIFACT SKDUPD message worksDiagram of the UN/EDIFACT SKDUPD Schedule update message. Travel service provider, such as a rail or bus operator sends it to other providers, authorities or timetable publishers. It usually follows SKDREQ. Inside the UIB and UIH envelopes, the directory D.21A requires, in the start of message: MSD (Message action details), ORG (Originator of request details) and HDR (Header information) and body and segment groups: the required SG2 loop with PRD (Product identification). 3 conditional segment groups are listed by their trigger segment.How the EDIFACT SKDUPDmessage worksSchedule update: who sends it, where it fits andwhat the directory marks mandatory1 WHERE IT FITSUSUALLY FOLLOWSSKDREQSchedule requestSKDUPDSENDERTravel serviceprovider, suchas a rail or busoperatorRECEIVEROther providers,authorities ortimetablepublishersUSUALLY FOLLOWED BYNo business reply expected2 WHAT DIRECTORY D.21A REQUIRESInteractive interchange (UIB … UIZ)Message SKDUPD (UIH … UIT)START OF MESSAGEMSDMessage action detailsORGOriginator of request detailsHDRHeader informationBODY AND SEGMENT GROUPSMandatory group SG2 · repeatsmany timesPRDProduct identification+ 3 conditional groups, starting with:ERISERPOPBlue 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 SKDUPD.Your trading partner's implementation guide adds itsown requirements.

How to read this diagram: the top row shows who sends SKDUPD, 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 SKDUPD 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 usually makes some conditional groups mandatory, restricts the codes and may use an older directory.

Expand diagram Download SVG

When it is used

  • Distributing new timetables to partners
  • Updating schedules for changes and disruptions
  • Supplying schedules to journey planners

Where it fits in the message flow

Usually follows SKDREQ Schedule request
This message SKDUPD Schedule update

Structure

Mandatory segments in SKDUPD (directory D.21A)

In UN/EDIFACT directory D.21A, the SKDUPD message has 45 segment positions arranged in 10 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. This structure comes from one published copy of the directory and has not been independently verified: confirm it before you build a map.

  • UIH
  • MSD
  • ORG
  • HDR
  • SG2 (PRD)
  • UIT

Practical example

SKDUPD in practice

A rail operator introduces its winter timetable. It sends ticketing partners, the traffic authority and a journey planning provider SKDUPD messages with every service, its stops, times and operating days. The partners load the timetable so tickets and journey plans reflect the new services from the change date.

Implementation

Implementation considerations for SKDUPD

  • Send static location data (TSDUPD) before schedules that reference it.
  • State the validity period of each schedule.
  • Handle changes and cancellations as updates.
  • Coordinate with partners on the timetable change date.

How ECOM helps

Automate SKDUPD with ECOM

Industry

Trucking and Transportation

Load tenders, responses, status and freight invoices for carriers, brokers and shippers, integrated with the TMS.

Industry

Hospitality

Procurement, invoicing and supplier integration for hotels, restaurant groups and foodservice suppliers.

Solution

EDI Integration

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

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

Related messages

Related travel and tourism messages

All 16 travel and tourism messages

Need help with SKDUPD?

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

Request a Demo Contact us