COMPANY MESSAGING AND ATC MESSAGING HAVE DIFFERENT AUTHORITY
Company ACARS supplies operational information such as loading messages, delay exchanges and diversion-related data. Check identity, edition and timing before using a message in the preparation. The preliminary, final and revised-final load figures can belong to different stages of the same sector. Follow a revision through actual loading, MCDU mass/fuel entries, trim and any performance recalculation it affects. A message becoming available or being acknowledged does not itself establish that the aircraft has been brought into agreement with it. [93, PDF pp. 1–4]
A company message is not an ATC clearance. Keep route proposals, operational estimates and loading information separate from authorisation to move or change the flight path. CPDLC/PDC additionally depends on the selected communications provider, available service and the interaction required by that system. The FM section documents the verified provider-specific programming and acknowledgements. This OPS chapter does not convert one provider's login or message sequence into a universal Hoppie, BeyondATC or Fenix recipe. Identify what was requested, what was received and what authority the received message actually has. [94, Official CPDLC guide; embedded tutorial and implementation scope] [93, Company ACARS message scope]
The printer is another presentation path, not another source of authority. Fenix documents manual printing from received AOC messages and optional automatic output or an external notification service. Its guide notes that automatic printing can mark a message viewed and change the normal COMPANY MSG presentation. Therefore, define how the crew will notice and review an incoming revision when that option is enabled. Absence of the familiar cockpit alert is not sufficient evidence that no message arrived. Keep the accepted record identifiable alongside the sector. [120, PDF p. 4]
For external printing or notification, verify the configured destination and preserve service credentials appropriately. Use the current service/provider instructions rather than an old quoted price or capacity as a permanent technical fact. A notification that reaches a telephone still needs the same aircraft and flight-identity check as a message read on the MCDU. During troubleshooting, compare reception in the aircraft with the external output result. That separates an ACARS request/reception problem from a printer, browser or notification-service problem. [120, Printer and Pushover setup; credential and output guidance] [93, Message identity and data checks]
Practise a revised loadsheet or route request while stopped before adding it to a busy taxi or arrival. Preserve the received version, describe the required aircraft changes and then verify their completion. If a message or uplink is unexpectedly directed to a secondary flight plan, inspect that plan rather than assuming the active route changed. Use the dated implementation notes when relevant, but retain the distinction between a reported software behaviour and the operational review that remains necessary in every build. [110, AOC SEC F-PLN UPLINK after INIT REQUEST] [93, Revised loading and performance entries] [83, Dated loading/flight-plan implementation findings]