ZSE controller reported the eram computer indicated rerouted aircraft upon departure then attempted ...

Narrative:

Air carrier X and air carrier Y filed almost identically as follows: yvr..tou..sedar..4300N/13000W..hekab.A332.[flight plan route].ZZZ respectively.both aircraft departed cyvr. After departure; but prior to sector 3 having a datablock/tracked target; eram performed a (mod) modification to the flight plans by rerouting them direct tou. Once eram did this; the fp's showed up with a lat/long direct tou along with an unsuccessful transmission message (utm) to zak. After querying sector 3; they said they did not reroute the aircraft direct tou and when they eventually did a reroute; it was direct sedar and only after they had the aircraft tracked up. Eram is rerouting these aircraft as soon as it sees the limited beacon code; even though ZSE is neither displaying the datablock nor has control of the datablock. When eram does this the utm occurs on a regular basis with these particular flights. In addition; this anomaly produces many strips with greatly varying times over sedar. With the utm there was no indication of the information that was unsuccessful (not passed); so it causes an extra workload by having to pass complete fp's unless you can figure out what didn't pass.recommendation; prevent eram from arbitrarily rerouting these flights and subsequently causing unnecessary utm's.

Original NASA ASRS Text

Title: ZSE Controller reported the ERAM computer indicated rerouted aircraft upon departure then attempted unsuccessfully to forward the flight plan information to ZAN. This resulted in extra coordination and workload to insure all parties had accurate information.

Narrative: Air Carrier X and Air Carrier Y filed almost identically as follows: YVR..TOU..SEDAR..4300N/13000W..HEKAB.A332.[Flight Plan Route].ZZZ respectively.Both aircraft departed CYVR. After departure; but prior to Sector 3 having a datablock/tracked target; ERAM performed a (MOD) modification to the flight plans by rerouting them direct TOU. Once ERAM did this; the FP's showed up with a lat/long direct TOU along with an Unsuccessful Transmission Message (UTM) to ZAK. After querying Sector 3; they said they did not reroute the aircraft direct TOU and when they eventually did a reroute; it was direct SEDAR and only after they had the aircraft tracked up. ERAM is rerouting these aircraft as soon as it sees the limited beacon code; even though ZSE is neither displaying the datablock nor has control of the datablock. When ERAM does this the UTM occurs on a regular basis with these particular flights. In addition; this anomaly produces many strips with greatly varying times over SEDAR. With the UTM there was no indication of the information that was unsuccessful (not passed); so it causes an extra workload by having to pass complete FP's unless you can figure out what didn't pass.Recommendation; prevent ERAM from arbitrarily rerouting these flights and subsequently causing unnecessary UTM's.

Data retrieved from NASA's ASRS site as of April 2012 and automatically converted to unabbreviated mixed upper/lowercase text. This report is for informational purposes with no guarantee of accuracy. See NASA's ASRS site for official report.

Attributes
ACN	984290
Time
Date	201112
Local Time Of Day	1801-2400
Place
Locale Reference	ZSE.ARTCC
State Reference	WA
Aircraft 1
Make Model Name	B737-800
Operating Under FAR Part	Part 121
Flight Phase	Climb
Flight Plan	IFR
Aircraft 2
Make Model Name	B737-800
Operating Under FAR Part	Part 121
Flight Phase	Climb
Flight Plan	IFR
Person 1
Function	Enroute
Qualification	Air Traffic Control Fully Certified
Events
Anomaly	ATC Issue All Types Deviation - Procedural Published Material / Policy

ZSE controller reported the eram computer indicated rerouted aircraft upon departure then attempted unsuccessfully to forward the flight plan information to zan. This resulted in extra coordination and workload to insure all parties had accurate information.