Galileo Credit Control Integration

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 support
and 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 by
him 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
THEORETICALASPECTS
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”
request (optional)
• 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”
request (optional)
• 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 TRAVELAGENCIES
6.1 PROBLEM DEFINITION:
Non IATA Travel Agencies are restricted to use Galileo GDS in effective manner.
Such as
1. 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

Galileo Credit Control Integration

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Galileo Credit Control Integration

Ähnlich wie Galileo Credit Control Integration (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Galileo Credit Control Integration