Narrative:

Throughout our flight sequence leading up to the incident flight; my first officer (first officer) and I noticed that my first officer's ACARS password would not be automatically uploaded / entered into the ACARS initialization page after my first officer would 'activate' the flight on his efb. Since it was the beginning of the roll out of this feature; we did not think anything of it and simply manually entered his ACARS password. On the ZZZ1 to ZZZ2 flight; we were at a no ACARS station and needed to do a manual manifest via the manifest applet. Upon entering all of the relevant info into the applet and hitting 'calculate manifest;' we would receive the following error message: (note: when the 'aerodata' switch was off) 'unable to store manifest. Try again later or call dispatch manifest information.' the following error occurred: 'procedure of function 'mm i fvmanifest' expects paramter @capt'; which was not.' when we tried to send the manifest with the aerodata switch on; we received a message saying that my ACARS password was entered but my first officer's was not (dashes appeared where his password should be).after calling dispatch and trying to do an 'over the phone' manifest; my dispatcher told me that he was receiving the same error message (I had read it to him to verify it was the same). While I was doing this with dispatch; my first officer called the efb helpline to get their help. We spent about 30 minutes on the phone with both the dispatch supervisor and the efb helpdesk trying to get the manifest to store but we were never able to do so. To allow us to leave ZZZ1; the dispatch supervisor; my dispatcher; my first officer; and I all agreed that the manifest was valid and that I could retain an electronic copy of the manifest that I could carry to the destination (the manifest was in the 'view manifest' area with data on or off). To be positive of this; I also took a screen shot of the page with the manifest solution and took a picture of it on my cellphone. Dispatch took down all of the info and told me they would save it locally (on paper I guess) until they could fix the software issue and save it electronically. We then departed and flew the flight uneventfully. When we got to ZZZ2; my first officer was able to update the version of flightview he was using. Once he performed this update; his ACARS password began uploading automatically into ACARS on each subsequent flight. To my knowledge; my first officer did not receive any notifications or electronic reminders that his flightview version was not the most recent. To my knowledge; he did update to version 1.3 per an foib we received several weeks back however; he had just returned the spare efb he had been using for the last 2+ weeks prior to starting this trip.I am not sure how this software issue came about but the only thing I can think of is that there really is no primary means of telling the user when flightview is out of date (at least in a similar; more obvious way like flight deck pro or company manuals). I do not have much more info about this on my end. In the future; the best prevention for this seems to be a more obvious pop-up reminder or warning message that tells the user that flightview is not up-to-date. Hopefully if this is worked into the software; we can avoid similar delays due to unknown system errors.

Related reports:

Google
 

Original NASA ASRS Text

Title: CRJ-200 Captain reported difficulty loading the correct password into a flightdeck crewmember's ACARS Initialization page.

Narrative: Throughout our flight sequence leading up to the incident flight; my First Officer (FO) and I noticed that my FO's ACARS password would not be automatically uploaded / entered into the ACARS Initialization page after my FO would 'activate' the flight on his EFB. Since it was the beginning of the roll out of this feature; we did not think anything of it and simply manually entered his ACARS password. On the ZZZ1 to ZZZ2 flight; we were at a NO ACARS station and needed to do a manual manifest via the manifest applet. Upon entering all of the relevant info into the applet and hitting 'calculate manifest;' we would receive the following error message: (note: when the 'AeroData' switch was OFF) 'Unable to store manifest. Try again later or call dispatch manifest information.' The following error occurred: 'Procedure of function 'mm i FVManifest' expects paramter @Capt'; which was not.' When we tried to send the manifest with the AeroData switch ON; we received a message saying that my ACARS Password was entered but my FO's was not (dashes appeared where his password should be).After calling dispatch and trying to do an 'over the phone' manifest; my Dispatcher told me that he was receiving the same error message (I had read it to him to verify it was the same). While I was doing this with dispatch; my FO called the EFB helpline to get their help. We spent about 30 minutes on the phone with BOTH the Dispatch Supervisor and the EFB helpdesk trying to get the manifest to store but we were never able to do so. To allow us to leave ZZZ1; the Dispatch Supervisor; my Dispatcher; my FO; and I all agreed that the manifest was VALID and that I could retain an electronic copy of the manifest that I could carry to the destination (the manifest was in the 'view manifest' area with data on or off). To be positive of this; I also took a screen shot of the page with the manifest solution and took a picture of it on my cellphone. Dispatch took down all of the info and told me they would save it locally (on paper I guess) until they could fix the software issue and save it electronically. We then departed and flew the flight uneventfully. When we got to ZZZ2; my FO was able to update the version of FlightView he was using. Once he performed this update; his ACARS password began uploading automatically into ACARS on each subsequent flight. To my knowledge; my FO did NOT receive any notifications or electronic reminders that his FlightView version was not the most recent. To my knowledge; he DID update to version 1.3 per an FOIB we received several weeks back however; he had just returned the spare EFB he had been using for the last 2+ weeks prior to starting this trip.I am not sure how this software issue came about but the only thing I can think of is that there really is no primary means of telling the user when FlightView is out of date (at least in a similar; more obvious way like Flight Deck Pro or Company Manuals). I do not have much more info about this on my end. In the future; the best prevention for this seems to be a more obvious pop-up reminder or warning message that tells the user that FlightView is not up-to-date. Hopefully if this is worked into the software; we can avoid similar delays due to unknown system errors.

Data retrieved from NASA's ASRS site 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.