Improved ETA/ETD Handling

With the increasing digitalization of transportation service providers but especially also the rising popularity of visibility platforms,a proper handling of ETA and ETD in TM was a missing piece for quite some time.

In the past there was a “dirty” workaround by using delay events for that scenario, but this wasn’t really feasible.

With the new cloud release 2208 and the upcoming on-premise release 2022, we finally spent some effort to introduce a proper handling of ETA and ETD updates.

What is ETA/ETD?

First things first. What does ETA/ETD stand for. It’s “Estimated time of arrival/departure”. It is usually reported during execution to give an early indication if there are any deviations from originally planned departure or arrival times. ETA is either reported from the executing party like ocean carriers or they are calculated by a visibility provider, based on real time location updates of the truck and predicted driving times.

This is of course very beneficial as both sending and receiving party have a chance to adapt follow-up processes ahead of time, when deviations can be expected.

Integrating ETA/ETD into TM

Of course it makes a lot of sense to actually integrate those Updates into Transportation Management and the connected components and here is how we do it.

The basis for it is the introduction of two new standard event codes EXPECTED_ARRIVAL and EXPECTED_DEPARTURE.

ETA/ETD Event Code

This events can now be reported via our standard TransportationEventBulkNotification_In Message. Example message below:

<glob:TransportationEventBulkNotification xmlns:glob="http://sap.com/xi/SAPGlobal/Global">
	<MessageHeader>
		<CreationDateTime>2022-07-31T12:36:03.728Z</CreationDateTime>
		<SenderParty>
			<InternalID>17386001</InternalID>
		</SenderParty>
	</MessageHeader>
	<TransportationEventNotificationMessage>
		<MessageHeader>
			<CreationDateTime>2022-07-31T12:36:03.728Z</CreationDateTime>
			<SenderParty>
				<InternalID>17386001</InternalID>
			</SenderParty>
		</MessageHeader>
		<TransportationEvent>
			<Event>
				<EventTypeCode>EXPECTED_ARRIVAL</EventTypeCode>
				<EventReasonCode/>
				<EventReasonText>I know best when this truck arrives</EventReasonText>
				<EstimatedDateTime>2022-05-11T20:10:00Z</EstimatedDateTime>
				<ActualDateTime>2022-05-03T20:10:00Z</ActualDateTime>
				<Location>
					<InternalID>0017100001</InternalID>
				</Location>
			</Event>
			<ObjectReference>
				<TransportationOrderID>6600006207</TransportationOrderID>
			</ObjectReference>
		</TransportationEvent>
	</TransportationEventNotificationMessage>
</glob:TransportationEventBulkNotification>

As all events they are visible in the execution tab of the freight document. They show the new estimated time as well as the original planned time before the ETA, so deviations are in fact stored in the system and can be used for analysis. Subsquent ETA/ETD events for the same location will update the existing event, compared to Delay events in the past where each event was stored seperately.

Based on the location the system will identify the affected stop and update the planned departure/arrival time based on the new estimated date time and set it to fix.

In case of road freight orders rescheduling will be called and the estimated date/time will be considered when updating the new transportation plan.

Basic ETA Update Process – Freight Order

For documents, which are not scheduled like freight bookings only the times reported via the message will be set, expecting that if there are dependant times for the received ETA on the booking (e.g. a change of expected arrival time at port of arrival will have impact expected arrival time at the delivery location), they will receive their own ETA.

Exception Handling in case of time conflicts

Hard setting planned times to the new ETA can of course also lead to temporary conflicts within the document itself, in case e.g. a new arrival time is later than the originally planned next departure of the freight document and the scheduler is not able to resolve this conflict due to constraints or we are in a booking scenario where scheduling is not available anyway.

Time Conflict after failed Scheduling

For these kind of conflicts we introduced a new document error, which will indicate that this inconsistency exists and has to be solved by the user.

Document Error – Time Conflict

The document error will be removed automatically once the document times are brought in a consistent state.