Mejores Prácticas para Ingresar Datos de Vuelo Seguro dentro del Perfil y Preguntas Frecuentes. Descripción: El programa de Vuelo Seguro que entrará en efecto el 1ro de mayo de 2009 requiere a las líneas aéreas proveer a la Administración de Seguridad en Transporte (TSA) con información específica del pasajero como nombre, fecha de nacimiento, y género. Para cumplir con los datos requeridos por del programa de Vuelo Seguro, la industria aérea ha acordado utilizar los campos existentes de SSR DOCS y SSR DOCO para transmitir la información requerida. Estos SSRs fueron parte de la resolución 760a de IATA que dio lugar al desarrollo de la información anticipada del pasajero (APIS) utilizando SSRs. Todos los GDSs de Travelport han implementado previamente estos SSRs y hoy están disponibles para que todos los clientes de Travelport los utilicen. Cuando se hizo el lanzamiento inicial en 2005, la industria requirió que cuando cualquiera de estos SSRs fueran utilizados todos los campos en el SSR contuvieran información. Si faltara información al momento de transmitir el SSR, se produciría un error. Más adelante la industria decidió quitar este requisito para que no fuera obligatorio que todos los campos tuvieran información. Como parte del proyecto de vuelo seguro, efectivo a partir del 1ro de mayo de 2009 Travelport quitará la restricción para incluir datos en todos los campos de SSR. Al quitar la restricción, las agencias de viajes podrán transmitir los datos que puedan recolectar al momento de hacer la reservación. El método para transmitir la información requerida por TSA (nombre, fecha de nacimiento, género) es a través de la función SSR DOCS. Y para transmitir la información opcional (el conocido número de viajero) será utilizando el formato SSR DOCO. Observe por favor que ninguna funcionalidad dentro del SSRs ha cambiado-los datos deben ser ingresados en el mismo orden como siempre. Todo lo que ha cambiando es que si no se tiene toda la información disponible de todas formas el SSR puede ser incluido en un PNR y estos datos parciales serán transmitidos por Travelport a la aerolínea. Mientras que la aerolínea sea la responsable de última instancia de proveer a TSA con la información de vuelo seguro, las agencias de viajes utilizarán los SSRs para transmitir los datos a las aerolíneas. Para más información sobre los APIS SSRs, utilice Formato de ayuda para el sistema Worldspan: INFO APIS. Para que los clientes se preparen para la implementación obligatoria las siguientes Mejores Prácticas son sugeridas: Secure Flight Profile Best Practice and FAQs – April 6, 2009 Page Para los suscriptores de Worldspan: 1. Colecte la información requerida del pasajero. 2. Para cualquier cliente que ya cuente con toda la información requerida en el SSR, puede crear un perfil o World File con un campo de transferencia (A) indicando siempre mover al record e ingresar el SSR con todos los datos, por otro lado si se ingresa el SSR con la información incompleta en el perfil (Word file) con línea de transferencia (A) dará lugar a un mensaje de error hasta que la restricción sea levantada el 1ro de mayo. 3. Para cualquier cliente con el que no se cuente con la información completa la agencia puede retrasar el incorporar el SSRs al perfil o construirlo utilizando un remark línea 5 con por lo menos un campo de información. Cuando se colecte la información adicional o se suprima la restricción, la línea de remarks puede ser modificada. Para crear un SSR en Worldspan: Aquí hay un ejemplo de cómo se deben de ingresar los formatos SSR DOCS en un PNR. Note que el -1 .1 al final del formato, asociar el SSR al campo de nombre 1. 3SSRDOCSYYHK1/P/MEX/S12345678/MEX/01MAR82/F/21JUN10/SANTANA/TERESA/H-1.1 O después del 1ro de Mayo, puede utilizarse de la siguiente forma: 3SSRDOCSYYHK1/////01MAR82/F//SANTANA/TERESA-1.1 Nota: Worldspan permite utilizar YY como código de línea aérea en lugar de ingresar el código de la aerolínea en específico. A pesar de que no puede añadir el formato SSR DOCS abreviado a un PNR antes del 1ro de Mayo, usted puede empezar a añadirlos a sus World Files ahora utilizando las líneas opcionales (O). Aquí están los pasos para agregar los formatos arriba mencionados a un World File: Para poner un World File en modo de modificación ingrese: G*-SANTANA/TERESA#PC 1. Para localizar líneas en blanco disponibles, ingrese: G*B 2. Tabule hacia alguna línea en blanco y añada el formato de DOCS como línea opcional “O”. Asegúrese de añadir el signo numeral (#) al final de la línea. Aquí hay un ejemplo: Secure Flight Profile Best Practice and FAQs – April 6, 2009 Page 610O( (3SSRDOCSYYHK1/////01MAR82/F//SANTANA/TERESA-1.1# ) 3. Pulse enter después de haber ingresado toda la información. 4. Para salvar, ingrese: G*ER Usted puede transferir todas las líneas opcionales (O) cuando este creando un PNR o después de haberlo hecho. Aquí hay dos ejemplos de formatos: Para transferir desde un World File: Todas las líneas (A) y la línea 610 Solo la línea 610 Ingrese: G*SANTANA/TERESA#C/6 0 G*C610 Secure Flight Profile Best Practice and FAQs – April 6, 2009 Page Para los subscriptores de Apollo y Galileo: 1. Colecte la información requerida del viajero. 2. Para cualquier perfil del cliente donde toda la información requerida en el SSR se haya recolectado, el SSR se puede crear en el perfil como línea de movimiento relacionada (R). 3. Para cualquier cliente que todavía no se haya colectado toda la información, la agencia puede retrasar la construcción del SSRs en el perfil o bien construirlo como una línea de movimiento relacionada (R) con la información limitada que haya recolectado. Si ingresa el SSR con la información incompleta en el perfil como línea de movimiento Relacionada antes del 1ro de mayo dará lugar a un mensaje de error. Para construir un SSR en Apollo: Aquí hay un ejemplo de cómo ingresaría los formatos SSR DOCS en un PNR. Note que N1 al principio del comando, asocia el formato del SSR al campo de nombre 1. ¤:3DOCSN1/P/MEX/S12345678/MEX/01MAR82/F/21JUN10/SANTANA/TERESA A continuación un ejemplo para agregar el formato de arriba a la línea 7 del perfil. Note que el formato N1 (Campo de Nombre 1) al principio del comando ha sido omitido. RC:7R/¤:3DOCS/P/MEX/S12345678/MEX/01MAR82/F/21JUN10/SANTANA/TERESA Cuando usted transfiere datos del perfil hacia el PNR, puede transferir las líneas R después de que los nombres y segmentos hayan sido añadidos al record. Aquí hay un formato para transferir las líneas R. MVP/R/P-1/+7 (Transfiere del PAR/ las líneas R /Campo de Nombre 1/ línea 7.) Para más información ver: HELP DOCS HELP PROFILE-MOVE Secure Flight Profile Best Practice and FAQs – April 6, 2009 Page Preguntas Frequentes P) ¿Cuándo serán suprimidas las restricciones del formato SSR DOCS para acomodar unicamente la información requerida por TSA—es decir los campos de nombre, fecha de nacimiento y género? ¿El SSR DOCS va a ser definitivamente el formato que se utilizara ya que algunas agencias han escuchado que será utilizado un OSI? R) Las restricciones que requieren que el SSR contenga todos los datos serán levantadas el 1ro de mayo. El campo SSR DOCS ha sido elegido por la industria como la solución. No se utilizara un OSI. P) ¿Qué responsabilidad tiene la agencia sobre las reservaciones creadas antes del 1ro de mayo de 2009 y que los pasajeros viajaran el 1ro de Mayo o después? R) La agencia no tiene ninguna responsabilidad de no haber incluido los datos requeridos por TSA hasta que las reservaciones se creen a partir del 1ro de mayo en adelante. P) ¿Será actualizado el programa Viewpoint (Galileo Desktop) de modo que los agentes puedan ingresar estos SSRs de forma gráfica (GUI) a través de Viewpoint? R) Viewpoint actualmente permite ingresar la información del pasajero (APIS) a través de SSRs. Viewpoint sí requiere que todas la información sea ingresada. Si un usuario requiere ingresar datos parciales, necesitará cambiarse Focalpoint para ingresar la información parcial y regresar a Viewpoint. No hay aún planes para realizar actualizaciones en Galileo Desktop para quitar estas restricciones de edición que solicitan todos los datos en el SSR. P) ¿La información en algún momento será protegida (encriptada) si el número de identificación del pasajero se convierte en parte de la información que TSA pueda requerir ya que a las agencias les preocupa la privacidad? R) No hay aún planes para proteger (encriptar) estos datos en los campos SSRs. Nótese que Travelport ha pasado las auditorias de PCI en los últimos años con la información contenida y a la vista en los campos SSR DOCS en la reservación. P) ¿Cuál es la longitud máxima del campo y la longitud de SSR DOCS? R) En Apolo/Galileo/Worldspan, La longitud de campo mínimo/máximo varía dependiendo de qué campo se quiera ingresar en el SSR. El número máximo de caracteres permitido en el SSR para Apollo o Galileo es de 180 y en Worldspan el máximo es de 127. Los límites de caracteres incluyen espacios y diagonales como separadores. Secure Flight Profile Best Practice and FAQs – April 6, 2009 Page P) ¿Travelport ha discutido con TSA para cerciorarse de que los 30 caracteres suministrados en el campo de observaciones de nombre cumplirá con los requisitos de TSA de 35 caracteres? R) 30 caracteres son el estándar que utiliza la industria para enviar mensajes en SSR DOCS. 35 es el máximo de caracteres que la línea aérea puede enviar a TSA. De acuerdo con el diseño del sistema de cada línea aérea, estas pueden agregar caracteres especiales a la información que Travelport les envía antes de que la aerolínea envíe la información a TSA. P) ¿Cuándo se utilizan los campos DOCS o DOCO existe una validación entre el nombre en el SSR y el campo de nombre en el PNR? R) No hay validación entre estos dos campos sin embargo se recomienda que sean iguales. El proceso que revisa el vuelo seguro utilizará el nombre ingresado en el SSR. P) ¿Qué procedimiento se debe seguir para las aerolíneas donde el PNR incluye a un infante viajando sin asiento y la línea aérea no permite ingresar en su sistema el nombre de este infante? R) No tenemos conocimiento de que exista alguna aerolínea que opere internacionalmente que no permita ingresar un campo de nombre para el infante. Debido a que es responsabilidad de la aerolínea el suministrar la información de vuelo seguro, la aerolínea deberá trabajar con el GDS para asegurarse de que se cumplan los requisitos. P) Mi cliente me esta preguntando: ¿Cómo manejar las situaciones en donde han creado un SSR y obtiene un mensaje de error como respuesta? "ERROR – NOT ALL DATA FIELDS ACCOUNTED FOR WITH DATA OR SLASH" ("ERROR- NO TODOS LOS CAMPOS DE DATOS FUERON INGRESADOS") R) Hasta el 1ro de mayo, la mejor práctica es ingresar solamente SSRs cuando se cuente con todos los campos. Después del 1ro de mayo ya no se desplegará este error debido a que la restricción de incluir toda la información en cada campo será suprimida. . Secure Flight Profile Best Practice and FAQs – April 6, 2009 Page P) Mi cliente no cuenta con todos los datos necesarios para ingresar el SSR. ¿Podría ingresar datos parciales? Ejemplo: ¿Si cuenta con el nombre y el género pero no con la fecha de nacimiento, ocurrirá un error al suministrar los datos? R) Una vez que las restricciones para los datos de SSR se supriman el 1ro de mayo, los agentes podrán ingresar datos parciales. Habrá algunas limitantes de edición tales como asegurarse que el campo de SSR incluya la letra P y el número del pasaporte, por ejemplo. Como se mencionó arriba existen mejores prácticas para que en Apollo y Worldspan se construyan SSRs en los Perfiles/World Files. Hasta el 1ro de mayo, las agencias pueden utilizar solamente SSRs que contengan toda la información requerida. P) ¿Los nuevos SSRs DOCO y DOCS dependen de una versión especifica de Apollo? R) Solo como recordatorio, estos SSRs no son nuevos tal vez no habían sido utilizados por su agencia, sin embargo estos SSRs no dependen de una versión específica y trabaja en todas las plataformas de Travelport GDS. P) En los ejemplos de ayuda HELP DOCS mostramos el segundo nombre, no obstante en el campo de nombres tal vez no incluimos el segundo nombre o inicial. ¿Necesitan estos dos campos estar igual? R) No necesitan estar iguales y no existe validación en los dos nombres entre estos campos. P) ¿Tiene el agente que ingresar el nombre completo del cliente en el SSR? R) El nombre ingresadó en el SSR debe ser el mismo que el que tenga en sus documentos el pasajero, por ejemplo el pasaporte. En el campo de nombre no hay variación se requiere de un apellido/primer nombre. En caso de no existir ningún primer nombre, el apellido puede ser repetido o se puede utilizar título. No habrá cambios en el procedimiento de ingresar nombres después del 1 de mayo, la agencia deberá continuar ingresando los nombres de la forma actual. P) Si la agencia tiene todos los datos requeridos en el Perfil/World File, ¿Cuál es la información mínima requerida en el PNR antes de transferir el SSR con los datos? R) Worldspan no requiere la presencia de segmentos aéreos. Debido a esto el SSR puede ser ingresado con una línea de transferencia de siempre mover al PNR, con la advertencia que el SSR está debajo del campo de nombre ya que este sí es requerido. Apollo sí requiere segmentos aéreos presentes, por lo tanto el SSR debe ser ingresado en el perfil con una línea de transferencia Relacionada y debe de ser parte de la selección de nombre. Secure Flight Profile Best Practice and FAQs – April 6, 2009 Page P) ¿Actualmente el agente no puede agregar el guión en el apellido en el campo de nombre de un PNR pero el SSR permitirá el guión? R) No hay cambio a la funcionalidad actual de GDS para los campos de nombre o SSRs. SSR DOCS sí permite ingresar el nombre con un guión esta funcionalidad está ya disponible para todos los usuarios de Travelport GDS. P) ¿Estamos seguros que el formato con las diagonales (//) para omitir el resto de la información no cambiara entre hoy y la implementación? R) La decisión para utilizar estos SSRs ha sido tomada por la industria y la aprobación final de la industria fue hecha el 27 de febrero de 2009. Quitar la restricción para permitir la transmisión de parte de los datos en el SSRs es el único cambio. El formato y la orden de ingresar los datos siguen siendo iguales. P) ¿Si las restricciones no serán levantadas sino hasta el 1ro de mayo, esto significa que el requisito del gobierno de suministrar esta información cambiará a una fecha posterior, pues los clientes no pueden esperar hasta el 1ro de mayo para comenzar a poner los SSR en perfiles? R) No se pronostica que la fecha del 1ro de mayo sea cambiada así que los clientes deben estar listos para funcionar operando esa fecha. El suministro de los datos no es un requisito del gobierno hacia la agencia. Como lo indicado arriba en mejores prácticas, los datos se pueden ser colectados hoy e ingresados en perfiles en todos los globalizadores del Travelport. Una vez que todos los datos han sido colectados e ingresados en el perfil, la agencia puede comenzar con éxito a transmitir estos datos a la aerolínea antes del 1ro de mayo. P) Para los formatos SSR DOCS. ¿Podremos utilizar el código YY para generar un mensaje a todas las aerolíneas en la reservación o necesitaremos hacer un SSR por cada aerolínea (y pasajero por supuesto)? R) Esta pregunta pertenece a los suscriptores de Worldspan ya que en este sistema los formatos SSR DOCS y SSR DOCO no funcionan por segmento. Por lo tanto el uso del código YY genera el mensaje a todas las aerolíneas en un PNR. En Apollo o Galielo no es necesario especificar código de aerolínea así que el uso del YY no se aplica. Secure Flight Profile Best Practice and FAQs – April 6, 2009 Page P) ¿Qué aerolínea es la responsable de enviar el SSR DOCS – la aerolínea que opera o la de vuelo de código compartido? Por ejemplo, si el vuelo es de código compartido con UA y el vuelo es operado por LH. ¿El agente necesita determinar si envía el SSR a UA a LH o utilizando YY? R) Los SSR DOCS y SSR DOCO como el resto de los SSRs continuarán siendo enviados a la línea aérea que comercializó el vuelo (código compartido) y ésta a su vez será responsable de enviar la información específica a la aerolínea que opera el vuelo. P) ¿Aumentará Travelport el número de SSRs que puede ser ingresados en un PNR como en los casos de grupos grandes que pueden exceder de los 255 permitidos hoy? R) No hay plan para aumentar el número de SSRs. Hoy hay un máximo de 255 SSRs y OSIs (combinados) que se permiten en el PNR P) Como lo entiendo la aerolínea tiene la obligación de transmitir la información y se espera que la agencia colecte esta información. Sin embargo, el pasajero no está obligado a proporcionar esta información a el agente, o posiblemente el pasajero no cuenta con esta información al momento de hacer la reservación. Está claro que el pasajero puede ser detenido por el departamento de seguridad si esa información no se suministra. Si el pasajero se niega a proporcionar esta información a la agencia, ¿Será la aerolínea responsable de colectar la información antes del abordaje? R) Sí, la transmisión de los datos de vuelo seguro es responsabilidad de la aerolínea y esta es responsable de proveerla 72 horas antes de la salida del pasajero. La recolección de datos es colaboración entre el pasajero, la agencia y la aerolínea. Para reducir al mínimo los trámites de todos las partes implicadas, es muy importante contar con la cooperación en la recolección y transmisión de los datos de vuelo seguro. P) ¿Puede mi agencia utilizar la herramienta de control de calidad (Custom Check) para cerciorarse de que este SSRs se está ingresando? R) El control de calidad llamado custom check si es capaz de verificar los campos de SSR según la regla solicitad así puede ser utilizado para la información del vuelo seguro. P) ¿Puede una agencia de Worldspan utilizar la herramienta de control de calidad llamada World File Edits para cerciorarse de que el SSRs ha sido utilizado? R) El producto World File Edits actualmente puede verificar según la regla la aplicación del SSR así que puede ser utilizado para la información de vuelo seguro. Secure Flight Profile Best Practice and FAQs – April 6, 2009 Page