Sunčana vura

For Sunčana Vura, we developed a modern business system for viewing, administering and processing airline tickets through the development of a custom web application for the travel agency. This involves the modernization of an internal tool that has been an important operational link between the GDS system and the daily work of agents for years. The old application retrieved reservations from Galileo, displayed ticket data, loaded some AIR information and supported basic administrative tasks.

Over time, industry formats changed, the amount of data grew, and the existing solution could no longer reliably keep up with the pace of daily work. That is why this project was not created as a visual refresh, but as the creation of a stable and long-term sustainable system that interprets complex GDS data accurately and displays it to users clearly, quickly and consistently.

The most important thing was to maintain the existing way of working. The processes remained the same, but the tool that supports them changed. The result is a web application that facilitates operational work, increases system reliability and creates a solid foundation for further development.

1. Starting points and analysis

The analysis focused on three questions:

• how the system reads and interprets data
• how it displays it
• how agents use it in real work

The challenges were:

• work with two different GDS sources: Galileo and Amadeus
• different and uneven data structures
• outdated architecture of the old system
• an operational team that works quickly and under pressure
• the need not to change the processes, but to modernize the underlying technology

The conclusion of the analysis was clear: the problem was not in the users or in the process, but in the fact that the old system could no longer keep up with the actual rhythm of work. It needed a system developed to work with GDS systems such as Amadeus and Galileo that can also accept manual unaligned entries from travel agents. An example of the development of a business web application that integrates multiple data sources and is adapted to work in real time.

2. Data sources

2.1 Galileo XML

Galileo delivers data in XML format. Although it is formally structured, it contains a large number of elements that are used only in special situations. The new solution therefore ensures:

• stable reading of XML
• precise interpretation of key elements
• data alignment before display
• display that respects the logic of the original channel

The system does not simplify Galileo “by force”, but translates its complexity into a consistent and understandable representation..

2.2 Amadeus AIR files

AIR is a much more demanding format. It is a textual industry standard in which the meaning of a single value often depends on the context, preceding lines, and business rules..

Therefore, a separate Node.js API has been developed that:

• reads AIR directly from the agency system
• parses data according to official Amadeus documentation
• normalizes it into a structured format
• ensures accurate interpretation of prices, passengers, FOM values and issuance labels

Correct reading of AIR is one of the key elements of professionalism of the entire system.

2.3 Amadeus printer output (TTY)

TTY output looks like plain text, but in practice relies on strict rules and meanings derived from position and context..

The system therefore uses a dual approach:

• displays the printout in the original format familiar to agents
• in the background, extracts and structures key information needed for further work

This maintains the familiar user experience, while still providing the system with the data it needs for processing and control.

3. What was the problem with the old system

The old system was not a problem because the process was bad, but because it could no longer keep up with changes in formats and the growth in the amount of data.

The main problems were:

• unstable interpretation of XML and AIR data
• rigid and difficult to upgrade architecture
• partial support for TTY format
• interface that became difficult to maintain over time
• performance degradation with larger data volumes

The consequence was that part of the technical burden began to be shifted to users.

4. How agents really work

The agent does not think about parsers, XML or AIR. He needs a clear overview from which he can read what is important in a second.

That’s why the new system is designed around the real way agents work:

• predictable information layout
• clean and stable table
• logically grouped data
• fast visual scanning
• consistent display regardless of data source

The best UI in the travel operating system is not the one that attracts attention, but the one that the user hardly notices because it works exactly as expected.

5. Solution architecture

The architecture is set up to keep all the complexity of the GDS format in the background, while the user interface remains simple and calm.

Key principles:

• Galileo and Amadeus remain logically separate
• Node.js API handles AIR and TTY formats
• Flutter CMS displays data in a stable and consistent form
• Administration and operations work within the same interface

It allows changes in data sources to be absorbed in the backend layer without disrupting the user experience.

6. UX and design philosophy

The UX was developed for working under pressure and with a large number of records. The goal was not a visual effect, but clarity and reliability.

The interface is built on:

• clear typography
• controlled information density
• repetitive structures
• minimal amount of colors
• clear distinction of data sources

A particularly important functionality is automatic refresh every five minutes. This way, the user works with current data without manual intervention, and the system remains “fresh” without interrupting the workflow.

7. Important system functionalities

7.1 Tickets overview

The system’s central screen displays reservations and key data in a single table, giving the agent a quick overview and minimal workload.

7.2 Separate source display

Galileo and Amadeus are displayed separately and clearly marked, thus reducing the risk of misinterpretation and maintaining the transparency of data sources.

7.3 AIR information overview

After parsing and normalization, AIR data is displayed in a readable form, without the need for the agent to manually read complex text files.

7.4 Printer integration

TTY output remains visible in the original, with parallel extraction of key elements for structured display and data verification.

7.5 Filtering and searching

Quick search and filtering by key fields allow the agent to find the requested booking in seconds without losing focus.

7.6 Administrative functions

Entering and editing merchant values, URA/IRA numbers and notes are unified within the same system, without the need for parallel records.

7.7 Pivot and export

The system allows exporting to Excel and working with pivot views for accounting, reporting and internal analytics purposes..

7.8 Automatic and manual refresh

Data is automatically refreshed every five minutes, and the user can immediately start a manual refresh if necessary..

7.9 Manual entry of reservations and tickets

The system also supports manual entry of records that do not come from the GDS, which leaves a single place of record even in exceptional situations..

8. CMS and administration

CMS is a central place where data is supplemented, harmonized and administratively processed. Its role is to transform technically retrieved data into business-useful information.

Enables:

• review and correction of key data
• entry of administrative values
• keeping notes
• manual entry of reservations and tickets
• central record of changes and decisions

Work that previously took place through additional Excel and auxiliary tools is consolidated into a single interface.

9. Security, stability and sustainability

In a system that processes reservations, tickets, and financial data, stability is not an added value but a basic prerequisite for operation..

Stability is achieved through:

• processing of complex formats in the API layer
• data normalization before display
• separation of Galileo and Amadeus logic
• controlled processing of TTY output
• modular architecture that allows for upgrades without breaking the whole

Such an approach allows for safe system growth and adaptation to future changes in the industry.

10. Future development

The system is designed to support further expansion without rebuilding the foundation. Potential upgrades include:

• adding new GDS channels
• expanding analytics and reporting
• new specialized views within the CMS
• additional administrative functions
• integration with financial and ERP systems
• more advanced segmentation by customers and partners
• automated validations and additional business rules

The value of the system is not only that it solves today’s needs, but also that it leaves room for future development without losing stability.

11. Conclusion

The modernization project for SUNČANA VURA shows how a complex business system can be technologically upgraded without changing the established way of working.

New solution:

• accurately interprets complex industrial formats
• reduces the user’s operational load
• combines review, administration and processing in one place
• creates a stable foundation for further development

For users, this means faster work, fewer errors and more confidence in data. For the organization, this means a long-term sustainable system that can grow along with the business.

If you are thinking about modernizing internal tools or developing a business application that must be stable, precise and sustainable in the long term, RedCode is available. We apply this approach in the development of other business applications for clients who work with complex data and operational processes.