A320
Dispatch Dispatcher
Situational Awareness
No Specific Anomaly Occurred All Types
General None Reported / Taken
Equipment / Tooling
There are fundamental flaws with the [Flight Plan Manager] system being used for US method of dispatch.  We have many situations where the software takes liberty changing paperwork/inputs without Dispatcher being made aware of them. For example after a Dispatcher creates a release by pressing the release button it is not sent to stations until after the [Load Report] is generated by AERODATA.  In the meantime the Dispatcher could leave the flight to look at other things.  However this releases the Dispatcher lock on the flight plan and the system will take liberty in changing parameters of the flight plan. If the Dispatcher were to return to the flight and not catch that there were changes made the Dispatcher could submit Release 1 with changes they were not aware of to the station to print. The system should not be able to make changes to the release after the Dispatcher has pressed release and creating a version of the flight plan. However whether that was the case in this this instance is probably not likely. However terrain page didn't even match the points presented in the remainder of the release [Flight Plan] legs page. The system creating paperwork that doesn't agree with itself is not OK and indicates a lack of robust programming and verification of data. Either way the system should be hardened and known vectors for the generation of incorrect paperwork locked down.
Air carrier Dispatcher reported operational issues could arise as a result of software anomalies.