Final report (1)

NIT Calicut, MCA 2013

Galileo Selling platform integration with TRAACS for Credit

Control Management AND

PNR Information Capturing from Galileo for Non IATA Travel Agencies

A PROJECT REPORT Submitted By:

HEMANT KUMAR

M100103CA

In Partial fulfillment for the Award of the Degree of MASTER OF COMPUTER APPLICATIONS

Under the guidance of Dr. S.D. Madhu Kumar

Head of Department, CSE Dept, NITC

DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING NATIONAL INSTITUTE OF TECHNOLOGY CALICUT

NIT CAMPUS PO, CALICUT KERALA, INDIA 673601

MAY 2013

1 HEMANT KUMAR


Acknowledge

I take this opportunity to express my sincere gratitude to all individuals, directly or indirectly, who have contributed towards the completion of this thesis.

I would like to express my heart-felt gratitude to my project guide Dr. S.D. Madhu Kumar, CSED, NITC and Suhail VP, NUCORE Software Solution, for their guidance, support and cooperation throughout this work.

Lastly, I thank all my friends, Classmates and Nucore colleagues for their supportand encouragement.

2 HEMANT KUMAR


Declaration

I hereby declare that this submission is my own work and that, to the best of my knowledge and belief, it contains no material previously published or written by another person nor material which has been accepted for the award of any other degree or diploma of the university or other institute of higher learning, except where due acknowledgment has been made in the text.

Date:

Name: HEMANT KUMAR

Signature:

3 HEMANT KUMAR


Certificate

This is to certify that the report on “Galileo Selling platform integration with TRAACS for Credit Control Management” and “PNR Information Capturing from Galileo for Non IATA Travel Agencies” submitted by Mr. Hemant Kumar(Roll No: M100103CA) to the National Institute of Technology Calicut towards partial fulfillment for the award of Degree of MASTER OF COMPUTER APPLICATIONS is a bona-fide record of the work carried out byhim under my supervision and guidance.

Signature of Internal Guide:

Place :

Date :

4 HEMANT KUMAR


Content

1. Introduction ...................................... 1 1.1 Problem Definition ...................................... 1 1.2 Solution Overview ...................................... 1 1.3 Back Ground Details ...................................... 2 1.4 Motivation ...................................... 3

2. Theoretical Aspects ...................................... 4 2.1 Designing Credit Control management system .............................. 4 2.1.1 CCMS Goals ...................................... 4 2.2 TRAACS Web Service ...................................... 5 2.2.1 TRAACS Web Service Goals ...................................... 5

3. Design ...................................... 7 3.1 Sequence Diagrams ...................................... 7 3.3 Use Case diagrams ...................................... 9

4. Implementation ...................................... 10 4.1 Credit Limit Control Process ...................................... 10 4.2 Credit Checking Based Upon Certain Amount .................................. 11 4.3 Credit Checking Based Upon No of Days .................................... 12 4.4 Credit Checking Based Upon Amount and Days ................................ 12 4.5 High Level Solution flow Diagram ...................................... 13

5. Solution Specific Details ...................................... 15 5.1 Launch Solution Process ...................................... 15 5.2 Form of Payment Check ...................................... 16 5.3 Retrieve the Customer ID or Account no ...................................... 16 5.4 Get the Available Credit Limit ...................................... 17 5.5 System Responses on Each Action ...................................... 18

6. Collecting the PNR information from Galileo ........................................ 29 6.1 Problem Definition ........................................ 29 6.2 Back Ground Detail and Objective ........................................ 30 6.3 High level solution flow ........................................ 31 6.4 System requirements ........................................ 31 6.5 New AIR XML file ........................................ 32

7. Conclusion ,,...................................... 33 References ........................................ 34

5 HEMANT KUMAR


ABSTRACT

Galileo selling platform is a mainly dedicated to contact with the Galileo GDS for booking airlines tickets. In that process there are many features we can add to make ASP more useful for travel agencies. One among them is Galileo Selling platform (Galileo GDS) integration with TRAACS (for Credit Control Management and New generation utilities to the travel ticketing users). It is designed for providing the credit information of a particular user before booking a ticket for him on credit basis since there is a strict restriction from travel agency side that they should allow him to get only fixed amount of credit and for fixed period of time. So the knowledge of credit balance information become very important for the travel agencies and our system will fulfill all those requirements and fill all the loop wholes of the ASP credit checking policies. The implementation needed lots of intensive study on Travel agencies to add necessary modifications and changes to make the system perfect and robust. The Outcome of the product has really fulfilled all the credit calculation requirements of a travel agency.

The benefits which Travel agencies will get from this project is

1. Overall command on ticket issues

2. Credit customer’s information will be available at any time.

6 HEMANT KUMAR


List of figures

Fig 3.1: Seq Dia when customer has credit balance ............................. 7

Fig 3.2: Seq Dia when customer has no credit balance .......................... 8

Fig 3.3: Use case diagrams for Travel agent ................................ 9

Fig 3.4: Use case diagrams for Travel agency manager .......................... 9

Fig 4.1: High level solution flow ................................ 13

Fig 4.2: Process flow ................................ 14

Fig 5.1: Active PNR ................................ 18

Fig 5.2: Form of payment (FOP) ................................ 19

Fig 5.3: Enter Customer ID ................................. 20

Fig 5.4: Customer ID ................................. 21

Fig 5.5: Invalid Customer ID ................................. 22

Fig 5.6: Fare is not quoted ................................ 23

Fig 5.7: Valid customer ................................ 24

Fig 5.8: Credit limit and grace days exceeded ................................. 25

Fig 5.9: Credit Days exceeded ................................. 26

Fig 5.10: web service down ................................,, 27

Fig 5.11: Issued Ticket ................................. 28

Fig 6.1: High level solution Flow ................................. 31

Fig 6.2: AIR XML File ................................. 32

7 HEMANT KUMAR


Chapter 1

INTRODUCTION

This section presents the solution designed by the Nucore Software Solutions for the generic Credit Limit Control Solution integrated with Galileo Selling Platform.

1.1 PROBLEM DEFINITION:

The Credit Control Management System is designed to run on the Galileo Selling Platform. It allows the Ticket Booking Agent to find out Credit balance of a Corporate Customer and controls the ticket issuance to a particular customer. There are few customers mainly corporate entities who wants to pay their booking bills once in a month or after a fixed period of time which depends upon the mutual understanding between Travel Agent and customer who gives certain credit for a fixed period of time, within that period customer can book his tickets till the credit balance is available.

The system has to check the credit balance every time when the customer books his tickets since the credit shouldn’t cross its limit. So every time the system has to check with their back office system (TRAACS) for his credit balance before proceeding with the booking.

1.2 SOLUTION OVERVIEW:

The generic Credit Limit Control Solution targets Multinational, Large and Medium sized Travel agencies which are mainly dealing with Corporate Customers.

The Credit Limit Control Solution is used to systematically check the available credit limit of the corporate traveler at ticketing time in reference to the credit limit stored in the TRAACS Back Office System (BOS). The solution requires that each corporate traveler is associated to a unique customer ID reference for which the credit limit is stored in the TRAACS BOS.

8 HEMANT KUMAR


The result of the credit limit check determines whether the ticket can be issued, if an approval has to be requested from the management or if the ticket issuance request should be rejected.

The available credit limit for a specific customer ID can also be displayed on demand at booking time.

Out of Scope

The development of the Credit Limit Control Solution does not include:• Any development on TRAACS BOS side which might be needed for adaption

with the Credit Limit Control Solution.• Any Credit Limit check on PNR segments other than Air segments• Credit Limit checks for E-ticket reissues and refunds.

1.3 BACKGROUND DETAILS:

GALILEO SELLING PLATFORM:

It is a complete package for Travel agencies who wants to book flight tickets for their customers .It has been built for communicating with GDS (Global Distribution System) and to get services from GDS.

GLOBAL DISTRIBUTION SYSTEM (GDS):

A worldwide computerized reservation network used as a single point of access for reserving airline seats, hotel rooms, rental cars, and other travel related items by travel agents, online reservation sites, and large corporation. The premier global distribution systems are Galileo, Amadeus, Sabre, and Worldspan. They are owned and operated as joint ventures by major airlines, car rental companies, and hotel groups. Also known as automated reservation system (ARS) or computerized reservation system (CRS).

9 HEMANT KUMAR


1.4 MOTIVATION:

Ticket booking agents who are using Galileo selling platform for booking airline tickets have to maintain their customers credit details since manually maintaining such details is a cumbersome process.

CCMS will provide great flexibility to manage the credit details by extracting some of the user information(Customer ID and Total Fare). We can manage the user credit information easily and it will avoid the manual work.

It reduces the cost as well as human effort in managing the sales with the credit data manually.

10 HEMANT KUMAR


Chapter 2

THEORETICAL ASPECTS

This section presents a description of the main functional components of the Credit Limit Control Solution.

2.1 Designing Credit Control Management System (CCMS):

It has been designed for extracting user information such as user ID and ticket fare amount of the current PNR.

CCMS will start triggering before giving TKPD command for booking the ticket. It will pause the System communication with GDS and give control over to the user for checking the customers’ credit balance by sending the customer details and fare details to the credit limit checking application (a separate TRAACS Credit Limit Checker implemented as a web service in TRAACS server).

CCMS Goals:

1. If the customer has credit balance then ticketing user can proceed with his booking.

2. If the customer has no credit balance then it should inform the customer about his credit limit as well as management.

Sub Goals:

If the customer has no credit balance but management requires to bypass this rule or allowing wavering to the customer for some period or increased limit, then the system has to allow the agent to book the ticket under some restrictions. A credit limit management settings will be required which can be managed in the TRAACS data base settings menu.Such as

1. Manager can increase his credit limit

2. Manager can change his due date

11 HEMANT KUMAR


3. Manager can disable CCM Checker for some time to allow the ticketing agent to book the ticket without verifying his credit limit. In this case agency has to maintain separate database table for such kind of booking or activities. That table contains only user ID with total fair of that transaction.

2.2 TRAACS Web Service:

TRAACS Web Service Application which will be installed in back office system where TRAACS back office server is configured. Logically TRACCS web service works between booking agent system and back office system.

After getting the details from CCMS, TRAACS Web Service will connect to TRACCS database which is back office system having the customer credit details. Once Web Service calculates the credit limit, the result will be returned to the CCMS system and based on the result command for TKPD will be passed or the TKPD issue on the active PNR will be blocked.

In this case we need to have the below requirements.

• The database services have to be maintained by NUCORE solution.• It contains total logic and process needed for extracting credit information from TRACCS database.

TRAACS Web Service Goals:

• It has to build up according to the TRAACS data base design.• It should apply the business logic required for calculating credit limit as per

TRAACS rules.• It has to install in both travel agent and back office system.

12 HEMANT KUMAR


To check the credit limit the procedure goes like this:

Step 1: The agent has to generate the PNR for the ticket booking.

Step 2: System will check for form of payment. If form of payment is Cash/Credit Card then credit calculation will not happen.

Step 3: The agent enter customer unique ID in notepad entry.

Step 4: Agent quotes the fare for ticket(it can be passenger wise/segment wise also).

Step 5: CCMS retrieves the total fare amount and customer information from the PNR and send those details to TRAACS Web Service.

Step 6: TRAACS Web Service which is running in between agent system and our back office will generate customer credit details from their database.

Step 7: TRAACS Web Service will extract the details from the result and get control back to the agent machine.

Step 8: Based on that result CCMS will issue the PNR.

13 HEMANT KUMAR


Chapter 3

DESIGN

Sequence Diagram:

This diagram illustrates internal behavior of the system when a process executes.

1. When customer has credit balance.

14 HEMANT KUMAR

Fig 3.1: Seq Dia when customer has credit balance


2. When customer has no credit balance.

15 HEMANT KUMAR

Fig 3.2: Seq Dia when customer has no credit balance


Use case Diagram:

This diagram explains how travel agent interacts with system to conduct desired action.

This diagram explains how travel agency manger interacts with system to conduct desired action

16 HEMANT KUMAR

Fig 3.3: Use case diagrams for Travel agent

Fig 3.4: Use case diagrams for Travel agency manager


Chapter 4

IMPLEMENTATION

Credit Limit Control solution is based on some conditions, it can be based on some amount, based on some days or based on days and amount. In each condition procedure will go as follows:

4.1 Credit Limit Control Process:

The Credit Limit Control Solution process includes the following functionality and steps:

• Intercept each TKPD command.

• Get Active PNR for process.

• Check if the form of payment is cash or Credit Card.

• Retrieve the customer ID from Notepad entry.

• Get Total Fare from FF field(Quoted Fare field) of PNR.

• Send Customer ID and Total Fare to TRAACS BOS to check the credit limit depending upon his credit checking condition(which has been set in the beginning).

• check for the result, if credit balance is available then it will go further for issuing the ticket.

17 HEMANT KUMAR


4.2 If the credit checking based upon a certain amount:

Compare the available Credit Limit with the sum of the Quoted Fare(Total Fare)

• If the available credit is above or equals the Total fare

• Send the previously intercepted TKPD command

• Update the available Credit Limit in the TRAACS database.

If the available credit is lower than the sum of the Total fare

• Display the message “Sufficient credit is not available”

• Send an email to the Management (and to the concerned staff) for the approval request (optional)

• Place the PNR on the Approval queue.

If the available credit is zero or less than zero

• Display the message “TKPD rejected due to insufficient credit”.

• Send an email to the Management (and to the concerned staff) to inform about the rejected ticket issuance (optional)

• Place the PNR on the Rejection queue.

P.S.- Each PNR in approval queue will be active only for 3 days, After that it will be deactivated by Galileo.

18 HEMANT KUMAR


4.3 If the credit checking based upon a certain days period:

Check every transaction status information

• If all the transaction status information is YES then

• Send the previously intercepted TTP command

• Add new transaction entry and update the Company profile or on the local or central database

If any of the Transaction status is NO

• Display the message “PNR needs approval”


• Place the PNR on the Approval queue

4.4 If the credit checking based upon amount and certain days period:

Check Above two conditions if both of them satisfies

• Send the previously intercepted TKPD command

• Add new transaction entry and update the Company profile on the local or central database

If both of them are not satisfied

• Display the message “PNR needs approval”


• Place the PNR on the Approval queue

P.S.- Each PNR in approval queue will be active only for 3 days, After that it will be deactivated by Galileo.

19 HEMANT KUMAR


4.5 High Level solution flow:

The process flow starts at ticketing time as soon as the TKPD command is intercepted.

20 HEMANT KUMAR

Fig 4.1: high level solution flow


21 HEMANT KUMAR

Fig 4.2: process flow


Chapter 5

SOLUTION SPECIFICATION DETAILS

This section presents a detailed description of the Credit Limit Control Solution process.

Note: The Credit Limit Control process is applicable for Air segments only.

5.1 Launch of the solution process

o Pre-Conditions The agent has sent a TKPD command o Post- Conditions

The Credit Limit Control Solution has been launched.

o Process description

The Credit Limit Control Solution is launched by the interception of a TKPD command.

5.1.1 TKPD command interception

The application intercepts all TKPD commands from the Command page. As soon as a TKPD command is intercepted, the Credit Limit Control Solution is launched.

The TKPD command interception includes all segment selections (i.e. TKPD/S1,3) or passenger selections (i.e. TKPD/P1-2) or it will issue all quoted fare in a PNR.

In case the TKPD command fails, the error message returned by Central System is displayed in a message box. The agent needs to handle the error message and to complete the ticket issuance manually.

22 HEMANT KUMAR


5.2 Form of payment check

o Pre-Condition

After the TKPD command interception the application has verified that an active PNR is present. o Post- Conditions

The form of payment has been checked whether it is Cash or Credit Card


The solution verifies existing form of payment elements in the active PNR.

In case the form of payment is Cash (FP CASH) or Credit Card (FP CC) the previously intercepted TKPD command is sent to issue the ticket(s).

If the PNR contains no FP element, an Input Box will be display with message “IS FORM OF PAYMENT INV(Y/N)”. if Y the application process continues with the retrieval of the customer ID or the account number else solution process will stop.

5.3 Retrieve the customer ID or the account number

o Pre-Conditions

The PNR contains at least one FP element which is not Cash or Credit Card.

o Post- Conditions

The customer ID or the account number for the active PNR has been retrieved.


The solution is configured to use the customer ID reference as customer reference for the Credit Limit check.

23 HEMANT KUMAR


5.4 Get the available Credit Limit for the customer reference

o Pre-Conditions

The customer reference has been retrieved from the NP entry.

o Post- Conditions

Depending on the configured solution option (one of the three), the web service application will send the retrieved information to associated TRAACS database to retrieve the Credit Limit data for the customer reference.


The Credit Limit Control Solution needs to get the available Credit Limit for the provided customer reference in order to validate the requested ticket issuance. The Credit Limit information is stored in the TRAACS BACK Office System. There is no communication between the BOS and the Credit Limit Control Solution.

Note: The requested Credit Limit data details are :

• Customer name

• Credit Limit amount & currency

• Current Balance (amount & currency)

• Available Credit

• Customer Type (optional)

• Last updated (date & time) (optional)

24 HEMANT KUMAR


5.5 System Responses on Each Action

Step1: Create PNR for a particular flight

25 HEMANT KUMAR

Fig 5.1: Active PNR


step 2: Checking form of payment

After creating a PNR agent have to give TKPD command and Credit control program will be launched.

After launching the program firstly system will check for form of payment. If form of payment is not available then system will ask whether FOP is INV or not. If yes system will go for further process.

26 HEMANT KUMAR

Fig 5.2: FOP


Step 3: Checking for Customer ID

The user has to follow the specified CUSTOMER ID format which is “CUST A002” If the user is not entered correct CUSTOMER ID then the system will ask him to enter the customer code.

27 HEMANT KUMAR

Fig 5.3: Enter Customer ID


If User entering form command prompt he must follow a predefined format. (Ex:CUSTXXXX)

28 HEMANT KUMAR

Fig 5.4: Customer ID


Invalid CUSTOMER ID Response:

29 HEMANT KUMAR

Fig 5.5: Invalid Customer ID


step 4: Checking for quoted Fare

if Fare is not quoted after generating PNR then system Response:

30 HEMANT KUMAR

Fig 5.6: Fare is not quoted


Valid customer and whose credit balance is not exceeded.

In this case our system will send TKPD command internally to book the ticket.

31 HEMANT KUMAR

Fig 5.7: Valid customer


Valid customer and his credit balance and grace period are exceeded:

32 HEMANT KUMAR

Fig 5.8: Credit limit and grace days exceeded


Valid customer and his grace period are exceeded:

33 HEMANT KUMAR

Fig 5.9: Days exceeded


If web Service is down then system Response:

34 HEMANT KUMAR

Fig 5.10: web service down


Issued ticket:

35 HEMANT KUMAR

Fig 5.11: Issued Ticket


Chapter 6

COLLECTING THE PNR INFORMATION FROM Galileo FOR NON IATA TRAVEL AGENCIES

6.1 PROBLEM DEFINITION:

Non IATA Travel Agencies are restricted to use Galileo GDS in effective manner.

Such as1. They can’t book the ticket.2. They can only generate PNR for a particular user.3. They can search for a particular flight on a particular date.4. They can use only limited features of Galileo. Non IATA Travel Agencies can generate a PNR for a particular flight and for a particular user and for issuing that PNR they transfer it to an IATA recognized Travel agency (which has collaborated with Non IATA agency) and they book(issue) the ticket for the sake of them. IATA travel agencies will share their profit depending upon their policy.

Since it is profit sharing business so it is important to store the data to avoid future conflicts. Till now Non IATA travel agencies stores this information manually which is time consuming process.

To make it more simple we are introducing a Back office capturing mechanism which provides collecting the information from the PNR and storing them in the back office.

36 HEMANT KUMAR


6.2 Back Ground Details and objectives

TRAACS working procedure:

Galileo will produce an AIR XML file after generating a ticket which contains all the information about that ticket.

What TRAACS does actually?

TRACCS has a capturing Mechanism which extracts all the valid and necessary information from AIR file and store into Back office.

Note: 1. AIR file will be generated after booking ticket so non IATA travel agencies cannot get this AIR file. SO our primary requirements are

1.Generating a New AIR file for a PNR which has been generated by a non IATA travel agency and booked by an IATA travel agency.

2. Rewriting the capturing mechanism to suit our new AIR file standards.

37 HEMANT KUMAR


6.3 High level solution Flow

6.4 System Requirements

• Galileo only run in INTERNET EXPLORER since it had developed using VB script.

• System must have installed windows XP or above version

• System must be installed with Galileo Selling platform

38 HEMANT KUMAR

Fig 6.1: High level solution Flow


6.5 New Air XML file format

39 HEMANT KUMAR

Fig 6.2: AIR XML File


Chapter 7

CONCLUSION

Credit limit calculation is an essential software for Travel agencies since their business scenarios has changed to suit present market conditions.

Our Credit limit software meets all the requirements and satisfies every objective condition.

It is solely made for the Galileo users and can be modified to suit other GDS services. It has been developed to change the Travel agencies credit system scenario and it is well tested before releasing in the market. It is a simple but very useful software and doesn’t need any extra knowledge other than working on Galileo and TRAACS.

Non IATA Travel agencies will be able to maintain their booking details as IATA travel agencies.

New AIR file generation is very simple and one can find it very systematic.

Future developments:

We can provide the same solution software for other GDS(Global distribution system)systems such as Amadeus , sabre.

40 HEMANT KUMAR


REFERENCES

[1]. GALILEO Development Company

+Script 3.0 Development Toolkit Sign-In Object Reference Guide

Document Version 3.0.2, November 2001 (Company Confidential) [2]. GALILEO Development Company

+XML API development notes – Reference Guide Document Version 3.0.2, November 2001 (Company Confidential)

[3]. Galileo ais, Educational Systems and Services

Copyright © 2004, Galileo ais [4]. Travel agency requirements.doc [Available]

Copyright © 2012, Nucore solutions

41 HEMANT KUMAR

Final report (1)

Technology

Transcript of Final report (1)