Web Fares Manag

Transcription

Web Fares Manag

Home
General Presentation
Web fares management
1. Input
1.1 Negotiated
(Fields description)
User Guide, version 3.6
Fares Specification tables:
1.1.1 Surcharges
1.1.2 Week-end
1.1.3 Taxes
1.1.4 ADVP
1.1.5 Ticket
1.1.6 Routings
1.1.7 Open Jaw(In fare line
specifications only)
1.1.8 Restricted Flights
1.1.9 Connectors
1.1.10 Rules
1.1.11 Black-Out
1.1.12 DOW
1.1.13 Fare Applicability
Webfares has been fully tested using Netscape 7 or Explorer 6
Revised by Itir Tansi
July, 2009
1.2 Commission Grid
1.3 Zones
2. Search
2.1 Negotiated
(see 1.1 for fields descriptions
and specification tables)
2.2 Commission Grid
2.3 Zones
Open your bookmark panel to see menu. Make sure that "hide after use" option is OFF.
3. General Info
3.1 Agency
3.2 Consolidator Info
3.3 Consortium
3.4 Credit Cards
3.5 Delivery Methods
3.6 Elegibility
3.7 Holidays
3.8 Pseudo Airline
3.9 Airlines
3.10 Airport codes
3.11 City Codes
3.12 Contracts
3.13 Extra Taxes
3.14 PCC information
3.15 Settings
3.16 Promotions
4. View
4.1 Negotiated
4.2 Taxes
5. Import
5.1 Excel Nego
5.2 Excel-Com.
5.3 Agencies
5.4 Taxes
6. Export
6.1 Contract=Y
6.2 Contract=N
6.3 All=Y
6.4 NFO-Nego
6.5 Agencies
7 . Utilities
7 .1 Mass Change Nego
7.1.1 Negotiated
7.1.2 Routing
7.1.3 Rest. Flights
7.1.4 Open Jaw
7.1.5 Seasonality
7.1.6 Week-End
7.1.7 Black-out
7.1.8 Surcharges
7.1.9 Rules
7.2 Mass Change C.G.
7.2.1 Comm. grids
7.2.2 Routing
7.2.3 Rest. Flights
7.2.4
7.2.5
7.2.6
7.2.7
7.2.8
7.3
7.4
7.5
7.6
7.7
Open Jaw
Week-end
Black-out
Surcharge
Rules
Mass Change Contract
Clean zones
Delete Contract
Clone contract
Auto zone
User Guide, version 3.6
Webfares has been fully tested using Netscape 7 or Explorer 6
Revised by Itir Tansi
July, 2009
Open your bookmark panel to see menu. Make sure that "hide after use" option is OFF.
Next page>>
<<Previous page - Next page>>
General presentation
The Web Fares Management System is a Consolidator application that allows the creation and
maintenance of all information related to:
-
Negotiated fares
Private fares loaded in the GDS
Published fares with commission override
'Pure' published fares
Web Fares (such as West Jet, Air Canada, etc...)
Consolidator profile All those fares will be interfaced to the Openfares Web Booking Engines:
B2B Business to Business
B2C Business to consumers
Openfares can interfaces with ALL the GDS: SABRE, GALILEO&APOLLO, WORLDSPAN, AMADEUS
You can display your fares to NFO (www.Netfaresonline.com) if you are a part of the NFO (Netfares
Online) platform.
- Negotiated fares (N):
Webfares allows the creation of negotiated fares from Airline contracts.
Negotiated Fares are identified with N.
-- Negotiated fares are always automatically offered on your booking engine.
- Private fares (N*):
Webfares allows the creation of commissions grids to identify mark-up on private fares.
These fares are Negotiated fares loaded in the GDS, therefore identified with N*
-- System will retrieve the private fares only if a commission grid is created.
- Published fares with commission overrides (C):
Webfares allows the creation of commissions grids to identify % overrides on published fares.
Published fares with commission overrides are identified with C
IMPORTANT: if a commission grid is created WITHOUT any override%, then fare will be displayed
with a P (instead of C). This will allow you to set some 'service fees' on fare for which you get no
commission override.
Commission grid fares (for both Private fares & commission overrides) are offered in your booking
engine if:
- In B2B, option Commission grids in Co-branding module is set to 'implicit' (or 'as an option')
- In B2C, fetch_pub option is set to 1 in the configuration file
- 'Pure published' fares (P):
Webfares allows management of general information regarding 'pure published' fares such as
service fees, credit card fees, etc.
'Pure' published fares are identified with P and a green dot.
The fare is a identified with a green dot because it is an 'available' fare provide by either:
- Super $BB for Galileo
- Trip Search for Sabre
- Power Shopper for Worldspan
- Power Fare for Amadeus
Pure published fares are offered in your booking engine if:
- In B2B, option Get best published fares option in C0-branding module is set to 'as an option'.
Then, the agent will have to select the WITH PUBLISHED option on the request page.
If you set this option to 'implicit', system will always retrieve the pure published fare.
This requires the proper set up and generates more 'hits' to the GDS.
- In B2C, option call_bff is set to 1 in the configuration file
NOTE: there is an option that will apply the commission grids on the 'green dot' fares for Galileo.
(you must contact Openfares).
If 'ON' you will then have 'green dots' fares identified with C (instead of P)
Backup Procedure
Backups of the OpenFares system is the responsibility of the OpenFares license owner, for a standalone installation (which is not true for the ASP platform, which is the responsibility of OpenFares).
In case disaster recovery is urgently needed, OpenFares guarantees a re-install of its
APPLICATIONS within the next hour following the customer's request. However, OpenFares cannot
be held liable for lost DATA or non-OpenFares HTML pages, so we do recommend our stand-alone
customers to take periodic backups of certain aspects of their Linux-based system. These fall into
the following 3 categories:
1) Databases
This is the most important thing to backup, as not backing them up would result in major data
losses in case of a major hacking, hardware or OS incident. The directory of your Linux server that
you have to backup in order to backup the databases usually is /var/lib/mysql . Because of
partitionning constraints on some pre-installed Linux systems, some installations can store their
databases in /home/mysql instead of /var/lib/mysql . If you are not sure in which of these 2
directories your databases are, you can look under the "[mysqld]" section of your /etc/my.cnf
configuration file, or enter a Melvin at www.aboutmelvin.com and an OpenFares technician will
promptly respond to your question.
2) HTML pages
This is definitely less important than databases, but backing them up will fasten an eventual crash
recovery and insure that the colors of the B2B booking engine will not be lost in case of a crash or
an accidental or malicious deletion of files. The directory for HTML pages usually is
/home/httpd/html . If your Web server was not configured accordingly to the OpenFares default
setup (for example, if your server was configured with "virtual hosts"), please check with your
network administrator for location of your OpenFares HTML directory(ies).
Note: the most important file(s) to backup in the HTML directory is the CSS (Cascading Style
Sheet) file(s) (*.css). If you have a large HTML directory and do not want to take it all in backup,
we would recommend that you at least take files with the ".css" extension anyway. In case of a
disaster recovery in which we do not have a backup copy of the CSS file, the B2B booking engine
will be reinstalled with its default colors. It will work, but not with all your look. These ".css" files
are very small and usually fit under 10 KB each.
3) Applications, configuration files and trace files
Applications themselves can be backed up for faster disaster recovery and possibility of an
OpenFares-independent disaster recovery procedure. The applications, configuration files and trace
files (note that the traces can be very big) usually are in /home/httpd/cgi-bin . As for the HTML
pages, it is possible that your network administrator have changed this directory, so double-check
with him/her if you're not sure.
However, if you do not take the OpenFares applications and traces in backup, OpenFares can easily
re-install them from their frozen versions. OpenFares has a copy of every version of the B2B, B2C
and WebFares systems since version 3.0 of the OpenFares system. However, it is ALWAYS
RECOMMENDED to take in backup the "webbooking/bk-engine" and "webbooking/custom*"
subdirectories of your "cgi-bin" directory, as they contain information that are specific to each
consolidator and therefore are not necessarly set the same way in your installation and in the
default installation of the booking engine, even both installations are the same version of the
OpenFares system.
To make your backups, please rely on a qualified technician. OpenFares does not provide any
guidelines in regards to installation of a tape-backup drive, installation of a redundant storing
architecture, automated backup procedure, etc. However, we can suggest to make backups with the
standard archiving command of Unix and Linux, "tar". You can take an archived and compressed
snapshot of your databases by changing to the directory of your databases (usually "cd
/var/lib/mysql") and issue the following command from the Linux prompt: "tar -zcf
nameofthebackupfile.tar *". This command will create a file called nameofthebackupfile.tar . You can
then move this file to another directory/partition of the same server, a remote machine or a
removable media.
1.Input Menu
To Input information related to Negotiated fares contracts and Commission grids.
Commission grids are used to specify overrides on published fares AND mark-up on Private fares.
1.1 Negotiated
The Nego. option is used to manually enter negotiated fares (Net fares) for a group of destinations and airlines with their related specifications. It
is also possible to load net fares using an excel file (see Import menu, Excel Nego option)
The specification tables can be linked to either a fare line, group of cities or the whole contract.
There are 3 levels for the specification tables:
Level 1 (S) Spec. button at end of fare line. Each fare line can have its own specifications.
Takes priority on all other specifications. Referred as fare line level specs as well. Level 2 (G) Global specifications tables at bottom of negotiated screen. The Global specifications will be related to the group of destinations
specified on top of page. Takes priority on contract specifications. Referred as page level specs as well.
Level 3 (C) Spec. button on top of Contract identification, under currency.
The specifications will be related to all fares in group of destinations that have the same contract identification. Referred as contract level specs as
well.
The * beside the specification table name indicates that the specification table contains information.
Special feature: Fareline "Rules" added to Contract level "Rules". Now we have a check mark box in the contract level SPECS of NEGO and
COMM GRID. If check mark is on, we will read the fareline level and contract level rules, both at the same time. This feature only associates the
fareline level rules and the contract level rule. It doesn't deal with the page level rules at all.
If you are using excel files to create contracts:
When fares are imported from Excel spreadsheets, the contract identification is the name of the excel spreadsheet. There can be multiple group of
destinations with the same contract identification.
All the specification tables will be created at fare line level (1).
If fare line was changed using Webfares only (and not in the excel file), changed information will be overwritten by excel information at fare line
level if re-imported without the change (if not also done in the excel sheet.
Any information entered at Level 2 or 3 using webfares is kept when a contract is 're-imported' (using the same name) therefore, it is NOT
overwritten because excel imports affect ONLY specs at fare line level.
If you are using Webfares to create contracts:
For each new fare line (in INPUT mode), you must click on 'save' at the end of each line to register the information in the database.
When you are in SEARCH mode, you can use the SAVE ALL button at the bottom of the page to update the full content of page OR the SAVE at
end of each line.
In both modes, the SPEC button will also save the line information and bring you to the specification tables.
In both cases:
If you input in webfares or import from excel negotiated fares, they are available through the booking engine only once you have Exported them
using the EXPORT, Contract = Y or manually set the 'Avail flag' to Y using the Search Negotiated.
KEY INFORMATION (mandatory):
The system will not keep the information if you input duplicate key information.
While you input directly in Webfares, if you modify key information, system will create another record with the different key.
You can modify Key information using Search Nego.
Key information in a fare line is:
Date from
Date to
Class
Type
Basis
OW/RT indicator
Suggestion:
You should create contract with Input Nego with only 1 fare line and save it.
Then, use the search Nego to continue the input.
You will then be able to modify all information with creating a duplicate record.
Order of data:
When you input fares directly in webfares, the system creates each fare line in the database with a fare line identification (number).
It attributes the fare line identification when you click on the spec or save at the right end of the fare line.
When you will use the Search nego, fare lines will be displayed sorted on the fare identification.
If you want to make sure that the fare lines are in the same order they where created you must click on the spec or save at the end of each fare
line in the proper order.
Fields description:
#id :
'Group of fares' identification number (fare_basis_id)
Fares are created using airport code(s) or city codes or zones:
(Gateway(s) OR Gateway Zone) AND (Destination(s) OR Destination Zone)
Gateway:
City(ies) or Airport(s) of origin for which the fares apply.
Gateways should be grouped together when same fare and same fare rules (such as min/max - mandatory nights - routings - etc...).
If you have more than one gateway they must be separated by ‘;’.
It must be either CITY codes (PAR) or Airport codes (CDG;ORY;LBG) but not a mixture of both.
- If a series of gateways are entered (2 or more) the system will automatically look for a matching Gateway zone and make the association. If
the system doesn’t find any match - it will automatically create a gateway zone.
Example: YUL;YVR
Dest:
City(ies) or Airport(s) of destination for which the fares apply.
Gateways should be grouped together when same fare and same fare rules (such as min/max - mandatory nights - routings - etc...).
If you have more than one destination they must be separated by ‘;’.
It must be either CITY codes (PAR) or Airport codes (CDG;ORY;LBG) but not a mixture of both.
- If a series of destinations are entered (2 or more) the system will automatically look for a matching Destination zone and make the association.
If the system doesn’t find any match - it will automatically create a destination zone.
Example: YYC;YVR
Zones:
Pre-determined zone identifying a group of city’s (or airport codes)
Gateway zone starts with a G
Destination zone starts with a D
Zones must have a minimum of 4 digits.
Example: GZONE01
Airline:
Airline for which the fares apply. There can be a maximum of 2 airlines. It must be the same value throughout the contract.
Example: ACLH or AC or ACYY
-->If no routings are entered:
System will use this airline(s) for availability search in the GDS and display availability only for this airline(s). If for example you have an AC
contract that is code shared with more than one airline (BA - AF - …), you can enter ACYY and specify the routings for each airlines in the
routings table.
In that case, system will request availability using AC availability search in your GDS and display all the results for AC or any other airline(s)
through AC's availability search.
-->If routings are entered (WITH VIA POINTS):
System uses the airline from the routing at the VIA POINT(s) to perform segment by
segment search(es) in the GDS (and not the airline that is specified here).
For example, routing AC;LON;BA with VIA POINT LON, system will query GDS the following way:
a) from origin to LON with AC
b) from LON to final destination with BA
-->If routings are entered (WITHOUT VIA POINTS):
System uses the airline specified in the Airline field for availability search and display only the results that match the routings entered.
Once contract is imported in webfares, you must set up the AIRLINE information (if not already existing) in Webfares/General info/Airline.
In search mode, the field airline name is a direct link to the Airline table.
Contract:
A contract should contain ALL the fares of the correspondant paper contract.
Once contract is created in webfares, you must set up the CONTRACT information (if not already existing) in Webfares/General info/contract.
The contract name MUST NOT contain any slash (/) nor spaces, especially if you intend to export your fares into the NFO database.
When a contract is created directly in webfares (or imported using Excel),
it is not yet available (AVAIL flag = N) on your website unless you set it available.
- You can set the whole contract available using the Export/Contract = Y
This will set the AVAIL = Y on all group of fares
- You can set the whole contract unavailable using the Export/Contract = N
This will set the AVAIL = N on all group of fares
- You can set available (or not) specific group of fares using the AVAIL flag (= Y or N) in the search nego or search commission grid options.
To test a contract through your LIVE booking engine without making these fares available to others, you can use your 'superuser' login (see
agency) that will display all the fares for you the fares regardless of the AVAIL flag value.
In search mode, the field name contract is a direct link to the contract table.
Currency:
Currency of price related information.
It must be the same currency as your PCC (Pseudo city code, GDS) settings.
Example: CAD or USD or BRL etc...
For each fare line:
Rep/del:
Repeat: The repeat button copies the information of the selected line onto the next line available.
You must change at least 1 key item of that new line (From/to, class, type, basis or ow/rt flag)
Make sure that you save your new line by clicking on the 'spec.' or 'save' button at end of line! System does not copy over the specification
tables. To do so, you can use the following buttons:
- Copy specs: To copy specs tables from 1 fare line (Id) to other(s)
or
- Copy rules: To copy only for Rules table from 1 fare line (Id) to other(s)
--> To indicate a series of fares id, you must enter it the following way:
100-110 (for lines 100 to 110)
--> To indicate specific line id(s), you must separate the numbers by a coma:
100,102 (for lines 100 and 102)
- Refresh: Click on refresh If you want the system to provide you with the fare line number (Id) of a new line.
Delete: The delete button is used to delete a fare line (only in search option). You must check mark the delete button and click on 'save' at the
end of the fare line.
Id.:
Fare line identification (fare_basis_det_id).
Used in copy rules and copy specs utilities.
To get the Id. while adding new lines in search mode, use the 'refresh' utility.
From/To :
From and To date of contract’s seasonalities.
Format: YYYY/MM/DD or YY/MM/DD or YYYY-MM-DD or YY-MM-DD
-> Note that date format is different in Excel (it is DD/MM/YY or DD/MM/YYYY or DD-MM-YY or DD-MM-YYYY ) but import program automatically
converts them into the Webfares format.
--> Once contract is created you must indicate if Season/wk-end based on trans. segment (in CONTRACT table) along with other contract
information.
Min/Max:
Minimum and Maximum stay (number of nights) requirements.
Once flights are selected, system will 'revalidate' the requirements using the arrival date
(at destination).
Example : Min 1, Max 1Y (or 365)
Values can be in formats such as: 30 or or 1M or 1Y
If you put 999 in minimum stay, the system will automatically use the mandatory nights to display minimum stay (must be a number) in the
following way:
Min: 999
Mandatory night stay : 5,6
Booking engine will display for minimum stay: Fri or Sat
If the minimum stay must be validated 'at destination', you must indicate it in the AIRLINE or CONTRACT table using the option: Mandatory night
at dest.
Night (s) :
Determines if the minimum stay requires specific nights of stay over.
Values are number 1 to 7 or A to G for Monday through Sunday.
If you use numbers it will mean ‘OR’ and if you use letters it will mean ‘AND’.
Example:
5,6 means minimum stay OR mandatory nights (Friday or Saturday)
E,F means minimum stay AND mandatory nights (Friday and Saturday)
You can not use letters in mandatory nights combine with the 999 because the system will think it is 999 days and the mandatory night(s).
Class:
Class of service of the fare.
Connecting flights (feeders) classes are determined in the routing table.
You must create 1 fare line per original booking class. This class in this column is the booking class of the main flight, as per the airline that
issued that net fares contract.
It is this class that will be shown at fare display and used for availability if no other classes are specified in the routing table for the connecting
flights.
Example : Q
Normally, the booking engine uses the fare TYPE to identify First class (fare type YF) and Business class (fare type YJ) for negotiated fares. It is
an option called 'use type for class' controled by Openfares for B2B and controled by the client for B2C (in B2C config. file). If you are not set to
use the fare type, then the system will use the class of fare.
For BUSINESS:
J
C
D
Z for AF/KL/NZ/CO/NH/LH/UA/SQ
I for AZ/LX/JL/BA
S for AC
For FIRST:
F
Type :
Fare type. Must be any 2 alphanumeric characters.
Examples: BL for Bulk, NG for negotiated, etc...
There are some 'Reserved' fare types: (with special properties in the booking engine)
YT Student Fares
YJ Business *
YF First Class *
LM Last Minute - last minutes fare lines can be displayed in a different colour on the B2B booking engine.
You can assign the last minute fare color through the B2B co-branding module and style sheets.
NB ‘Not bookable’ - the fare will be displayed in the booking engine but the agent will not be able to book the fare. A message will be displayed
to contact the consolidator. Additionnal message information to display is picked up in the first 2 rermark lines of the General info/consolidator
information - Remarks, in your Webfares. They can can also be displayed in a different colour on B2B booking engine.
You can assign the 'not bookable' fare color through the B2B co-branding module and style sheets.
AL For fares with allotment. This will indicate to control sales using the allotments in CONTRACT table. If no allotment is created, system will
consider the fare as a standard net fare.
* The default setting (controled by openfares) for B2B booking engine is set to use the FARE TYPE (instead of class) to determine First and
Business classes throughout the booking engine. If you do not want this, you must contact Openfares. Then, system will then base itself on
classes to determine First and Business.
The following fare types will be offered only when using the Add Flights in the B2B after original flight is booked. See B2B online documentation section 8.2 for more information.
CT Connector flight (at beginning of main flight) that can not be sold as main flight
AT Add on (at end of main flight) that can not be sold as main flight
AD Add on (at end of main flight) that can also be sold as main flight
ST Side trip (at stop over point of main flight)
--> PLEASE NOTE You can not have 2 (or more) fare lines with the SAME key information:
If so, the system will generate a DUPLICATE entry in the database and therefore it will not import in Webfares.
You will get a duplicate KEY error message with the fares line where it occurs.
THE MANDATORY KEY INFORMATION fields are: contract name - airline - gateway - destination - season (date from and to) - class - fare basis
- fare type - OW/RT.
Information such as routings, fare amount, min/max stay requirements and any infomation in the spcecification tables in webfares are not part of
KEY ITEM.
If you need more than 1 fare line with SAME key information (listed above) with DIFFERENT non key information you must make these fare lines
DIFFERENT from others using the FARE TYPE.
Example 1:
EK contract with interline (CO and DL) buy-ups: You have different FARES when using CO in L or T or Q and different FARES when using DL
You should do the following in contract EK:
1
1
1
1
fare
fare
fare
fare
line
line
line
line
with
with
with
with
Fare
Fare
Fare
Fare
type
type
type
type
NL (when CO is in L)
NT (when CO is in T)
NQ (when CO is in Q)
ND (when using DL)
Therefore:
YHZ to BKK fare with basis WKE3MCA5 - class W - High season with CO routings - L class - fare type NL
YHZ to BKK fare with basis WKE3MCA5 - class W - High season with CO routings - T class - fare type NT
YHZ to BKK fare with basis WKE3MCA5 - class W - High season with CO routings - Q class- fare type NQ
YHZ to BKK fare with basis WKE3MCA5 - class W - High season with DL routings - W class - fare type ND
Example 2:
NH contract where week-end surcharges are bases on outbound and inbound days:
To japan (Out) From Japan (In) Days
--- Fri +20 ----------- Fri +20 -- 5
--- Sat + 40 ---------- Sat +20-- 6
--- Sun +20 ---------- Sun + 40- 7
This means that week-end surcharge is $40 except if you leave on Saturday (Day 6) it is an additional $20, if you return on Sunday (Day 7) it is
an additional $20.
Because the week-end surcharge is based on direction, fares will be 'per direction' using the DIR field.
We will also use the DOW table at the end of each fare line.
a) you need a week-end surcharge of $40 with days OUT 567 days IN 567
b)
123-
You need 3 Outbound fare lines per seasons (DIR O): (repeat for each seasons)
season 1 - Type B1 basis MKXVFNH $745 with DOW OUT 1234 * (IN 1234567)
season 1 - Type B1 basis MKWVFNH $745 with DOW OUT 57 * (IN 1234567)
season 1 - Type B2 ** basis MKWVFNH $765 *** with DOW OUT 6 (IN 1234567)
c) You need 3 fares lines for the whole duration of the contract:
1- from/to dates that covers all seasons - type R1 basis MKXVFNH $0 with DOW OUT 1234567 IN 1234 *
2- from/to dates that covers all seasons - type R1 basis MKWVFNH $0 with DOW OUT 1234567 IN 56*
3- from/to dates that covers all seasons - type R2 ** basis MKWVFNH $20 *** with DOW OUT 1234567 IN 7
* These lines are duplicated only to get the proper fare basis at Fare display of the booking engine
** B2 and R2 fare type are used to make the KEY information different from fare line 2
*** Only $20 is added because there is already a $40 week-end surcharge on the fare.
Results in booking engine: On regular midweek fare of $695
- OUT Monday - IN Saturday -- fare is $715 basis MHXVFNH/MHWVFNH (+20)
- IN Sunday -- fare is $735 basis MHXVFNH/MHWVFNH (+40)
- IN Monday -- fare is $695 basis MHXVFNH/MHXVFNH (+0)
- OUT Saturday - IN Saturday -- fare is $755 basis MHWVFNH/MHWVFNH (+60)
- IN Sunday -- fare is $775 basis MHWVFNH/MHWVFNH (+80)
- IN Monday -- fare is $735 basis MHWVFNH/MHXVFNH (+40)
Basis:
Fare basis of midweek fare.
--> If you have a midweek fare of $500 for fare basis ZLX060 and week-end fare of $540 you can enter one fare line for ZLX060 of $500 and
enter the week-end surcharge of $40 with specific days out and days in (using the WEEK-END specification table).
Example: BHXAP
If there are entries in week-end table (ex: $40 567-567), the booking engine will know that it should add $20 per week-end segment and
automatically create the weekend fare basis ZLW060 and put it in the PNR for the week-end segment(s).
In fact - it replaces any X in the fare basis by a W when week-end fare applies. It is done at the time of booking (not at the fare display). If you
have a mixture of mid-week and week-end fare, system can insert both fare basis in PNR accordingly, for instance BHXAP/BHWAP. If you do not
have both OUT and IN fare basis in PNR, you can contact Openfares support, we simply need to adjust your PNR configuration file.
--> You can use the FB function in the stopover field of the routing table. If you enter FB(LAX/SFO) in stopover field of routing table, the system
will automatically replace the ZZZ in fare basis with matching value between selected route and airport
codes provided in the FB option in stopover field.
Example: ALZZZ05C
If route is going through LAX - fare basis will become ALLAX05C in PNR at time of booking.
If route is going through SFO - fare basis will become ALSFO05C in PNR at time of booking.
--> Wild cards such as @@ in basis V@@ART will become VLXART if mid-week LOW season fare (when using Openfares Ticketing module).
Net:
Consolidator Net fare (COST). No dots, comma and cents. Ex. 300
Mrk-up(s):
Mark-up of consolidator in dollars and/or percentage to determine SELL to travel agents
(through B2B booking engine)
- If mark-up is in dollars (amount equal or greater than 1, ex: 50), it will be added to NET in order to calculate the SELL: Net + Mark-up 1 +
mark-up 2 = Sell (500 + 50 + 0 = 550)
- If mark-up is in percentage (amount smaller than 1, ex: .91 or .15), you must coordinate with the following option in Webfares/General
info/Consolidator info: ADD mark-up % on Net
This is to indicate how to calculate the SELL using a percentage mark-up for negotiated fares.
- 2nd mark up field:
NET + 1st mark up / 2nd mark up = SELL or
NET / 2nd mark up = SELL
Round up/down:
This feature exits only in NEGO. It allows you to:
a) Round up or down your sell amount to the next 10. Check mark R for UP or D for DOWN
b) Round up or down the last digit of your sell to the value. Enter a single digit in "value" and check mark R for UP or D for DOWN. Example:
Your net is 900 your mark up is 50
c) Neutral Displays NET+ Mark up = SELL
Sell:
Selling price. Automatically calculated using the net and the mark-up (s).
- If mark-up is an amount: Net + Mark-up = Sell (500 + 50 = 550)
- If mark-up is a percentage there is 2 way to calculate the sell:
a) If the ADD mark-up % on Net is checked (default), it is a dollar amount mark-up on NET, therefore, percentage is added to Net:
Net + mark-up = Sell (500 + 15% = 575)
b) If the ADD mark-up % on Net isn't checked, it is a commission percentage mark-up on NET, therefore, Net is divided by percentage :
Net / mark-up = Sell (500/.91 = 549).
This is to ensure the consolidator has a 9% mark-up. (100 minus .91 = 9)
- If you put 2 different mark-ups, for example a combination of dollar AND percentage they will be added to Net in the sequence that they are
entered Net + mark-up 1 + mark-up 2 = Sell
example 1) mark-up 1 = 50 AND mark-up 2 = .02 --> 500 + 50 + 2% = 561
example 2) mark-up 1 = .02 AND mark-up 2 = 50 --> 500 + 2% + 50 = 560
Chd:
Child fare, determined by a percentage of the fare (net or sell)* OR a specific amount.
75 means 75% - percentage on the fare
150D means 150$ - child fare amount
blank field or 0 is considered as 100%, same as net adult.
*When using a percentage, Child fare is calculated using either the Adult Net or Sell fare, according to the following option
in Webfares/General info/Consolidator info: Child & infant on Sell or Net (S/N)
If on Net (N):
Example 1: Net: 613 mark-up: .91 (%) Child %: 67
Child fare = (Adult Net x child %) / mark-up = (613$ x 67%) / 91% = 451$
Example 2: Net: 613 mark-up: .10 (%) Child %: 67
Child fare = (Adult Net x child %) + mark-up = (613$ x 67%) + 10% = 451$
Example 3: Net: 613 mark-up 1: 50 mark-up 2: .02 Child %: 67
Child fare = (Adult Net x child %) + mark-up 1 + mark-up 2 = (613$ x 67%) + 50$ + 2% = 471
If on Sell (S):
Example: Sell: 674 Child %: 67%
Child fare = Adult Sell x child % = 674$ x 67% = 451$
Surcharges are included in net fare. Surcharges won’t apply if child or infant selling price is zero.
Inf:
Infant fare, determined by a percentage of the fare (net or sell)* OR a specific amount.
10 means 10% - percentage on the fare
50D means 50$ - infant fare amount
blank field or 0 is considered as 0%, free or N/A
If infant selling fare is the same as net adult, you must enter 100
* When using a percentage, infant fare is calculated using either the Adult Net or Sell fare, according to the following option
in Webfares/General info/Consolidator info: Child & infant on Sell or Net (S/N)
If on Net (N):
Example 1: Net: 613 mark-up: .91 (%) infant %: 10
Infant fare = (Adult Net x infant%) / mark-up = (613$ x 10%) / 91% = 67$
Example 2: Net: 613 mark-up: .10 (%) infant %:10
Infant fare = (Adult Net x infant%) + mark-up = (613$ x 10%) + 10% = 67$
Example 3: Net: 613 mark-up 1: 50 mark-up 2: .02 Child %: 10
Child fare = (Adult Net x child %) + mark-up 1 + mark-up 2 = (613$ x 10%) + 50$ + 2% = 115$
If on Sell (S):
Example: Sell: 674 Infant %: 10%
Infant fare = Adult Sell x infant% = 674$ x 10% = 67$
Surcharges are included in net fare. Surcharges won’t apply if child or infant selling price is zero.
Land :
Indicates that the fare must be sold with a land portion if check marked.
Land portions can be created using the SURCHARGE table.
O/W:
Indicates a one-way fare if check marked.
Dir.:
For directional fares and reversed fares.
Blank indicates that it is not a directional flight, fare is a normal return (round trip) fare.
Directional fares:
When fare is determined by outbound AND inbound dates.
O indicates that fare is applicable only for Outbound
I indicates that fare is applicable only for Inbound.
B indicates that fare is applicable for both ways (system will take the outbound fare + the inbound fare and divide it by 2)
So, you should use a combination of O and I fares OR only B fares (most common).
If O and I: Fare is per segment.
All the specification tables in Webfares (routings, rules, etc...) will be validated using the OUTBOUND fare information except for the RESTRICTED
FLIGHTS - they will be validated using information on both OUTBOUND and INBOUND fare.
The INBOUND fare will be added to the OUTBOUND fare information to create the applicable fare.
outbound: YYZ-LAX 10JUL 250$
inbound: LAX-YYZ 10SEP 450 $
applicable rate = 700$
Open Jaw/mix classes can be performed with directional fares (O and I) by entering regular open jaw rules.
The open jaw fare will be calculated based on applicable fares per destination at the percentage entered in the open jaw rules.
Ex: Open Jaw rules :
zone= 1 with zone = 1 type = AA with type = AA ratio = 50 YYZ LAX / MIA YYZ 10JUL TO 10SEP
outbound: YYZ-LAX 10JUL 250$
inbound: LAX-YYZ 10SEP 450 $
outbound: YYZ-MIA 10JUL: 500$
inbound: MIA-YYZ 10SEP:550$
Query result: 700$ + 1050$ = 1750$ / 2 = 875$ (Same results for mix class and up sales.)
If B: Return fares based on seasonalities OUT and IN.
All the specification tables in Webfares will be selected using the OUTBOUND fare except for DOW and RESTRICTED FLIGHTS.
Fare basis of Outbound and Inbound fare will be selected.
For example:
You have a return fare of $500 for dates from January 01 to January 31
You have a return fare of $550 for dates from February 01 to February 28
If you ask for departure January 15 and return February 15 - Query result will be $525 ($500+$550/2)
Open Jaw/mix classes can be performed with directional fares (B) by entering regular open jaw rules format.
The fare of the open jaw will be calculated based on applicable fares per destination at the percentage entered in the open jaw rules.
ex. Open Jaw rule: zone= 1 with zone = 1 type = AA with type = AA ratio = 50
YUL MSY / MIA YUL 11 june to 16 june
Outbound: YUL-MSY 11 june $537 + 44 surcharge
Inbound: MSY-YUL 16 june $622
Outbound: YUL-MIA 11 june $531 + 44 surcharge
Inbound: MIA-YUL 16 june $669
Query result will be $647 ($537+669 / 2 = 603 + 44 surcharge)
Reverse fares:
When fare can be sold in reverse using same fare and same routing (but reversed)
In order to use this option, it must first be set ON by Openfares.
By using this flag (instead of manually creating the reverse contract) it will affect response time of fare display because system needs to make a
double query into the database.
R indicates it is a reversible fare.
If fare is created YUL LAX $500 routing AC;YYZ;AA system will select this fare if a request is made from LAX to YUL and will use routing
AA;YYZ;AC
Inactive:
Date where the fare line becomes inactive. The WEB BOOKING engine will not display fares of inactive fare lines. Must be greater or equal to the
current date.
Format is : YYYY-MM-DD
1.1.1 Surcharge :
This table is used for many applications:
a) return surcharges: dates from and to, amount in Surcharge ($)
b) land portion surcharges: dates from and to, amount in daily OR pax OR trip
c) distribution surcharges: dates from and to, amount (or no amount) in Surcharge ($), distribution
code other than ALL.
Surcharges are added to the fare in the Web booking engine when applicable.
Only return surcharges are added to the cost.
Fields description:
Dates From /To :
Dates where surcharge is applicable. Surcharges apply on return dates.
Surcharge ($) :
Surcharge amount applicable by segment. You can enter negative surcharges.
Ex: -20
When you have contracts where Outbound and Inbound determine seasonality and difference is
always the same amount, here is how you can deal with those cases:
Example:
High season $600
Low season $500
($600 - $500 = $100 / 2 = $50)
In High season fares, you enter a surcharge of $-50 when return in Low season
In Low season fares, you enter a surcharge of $50 when return in High season
(you can use mass changes Surcharge)
Two weekend surcharges (Cost/Sell): Starting version 3.5 you can now enter two weekend
surcharge amounts (Example:50/60) separated with a slash. Applies to Nego and Comm Grid,
Webfares or Excel. First amount represents the round trip cost weekend surcharge, second amount
represents the round trip sell (cost + your weekend mark up) weekend surcharge.
Daily :
If you put $40 in the Daily field it will charge $40 per person, per night
Pax :
If you put $40 in the Pax field, it will charge $40 per night and divide the total by the number
of passengers travelling.
Trip :
If you put $100 in the Trip field, it will charge $100 for the whole trip and divide the amount
By the number of pax. The round up/down field allow you to indicate how to round the amount (if
necessary.)
Example : $100
If one passenger: $100 per pax
If 2 passengers: $50 per pax
If 3 passengers: $33.33 so $33 per pax (if round down) $34 per pax (if round up)
Book in class :
Allows you to indicate in which class the booking should be made for the return.
Example: YYC to BZE Low season V class, high season B class.
Distribution :
Identifies the distribution system in which the fares can be offered.
Blank = all (system will automatically insert ALL)
GDS;NFO;B2B;B2C;INT
If for example you want to add an amount for fares available through NFO (+10) and specify that
you wish to present those fares through all other distribution systems (with no additional
surcharge), you must enter a surcharge of 0 with ALL in the Distribution field.
--> In commission grids only, if you put COM in the distribution code, it will indicate that the
commission applies on the surcharge.
So if COM, Sell = (base fare + surcharge) – commission
If no COM, Sell = base fare – commission + surcharge
Key information: Date from/to
1.1.2 Week-End:
Week-end surcharges with applicable days.
For commission grids:
Week-end days are 567 outbound and 567 Inbound as default values in the fares display.
If they must be different, you must fill out the week-end days with the proper values in the weekend days (simply need to fill out From/To and Days out and in, no need to enter any amount
(Surcharge $), system picks it up from the GDS automatically.) If there must not be any default
week-end days displayed, you can put 9 in days out and days in.
For Negotiated:
For Return fares:
- The amount is divided by 2 when days out and days in are entered.
Half for outbound days and half for inbound days, if applicable.
Ex: $50 days in 567 days out 567
System will add $25 if outbound day is 5, 6 or 7 and another $25 if inbound is day is 5, 6 or 7
- If days out only is entered, system will use departure date to determine if week-end surcharge
applies and use the full amount.
Ex: $50 days in 567
System will add $50 if outbound day is 5, 6 or 7 (regardless of inbound days)
For one way fares:
A mount is not divided by 2 and no need to enter Days in.
Ex: $50 days in 567
System will add $50 if outound day is 5,6 or 7
In the booking engine:
If 'Season/wk-end based on trans. segment' is check marked in the contract table, the system will
not provide the week-end surcharge at the fares display.
(Because we need the selected itinerary in order to properly calculate the week-end using the date
of the 'overseas' segment)
It will calculate it once the itinerary is chosen. Like usual the system will display the following
message: Please note that a $30 week-end surcharge is included in the rate.
and include the week-end surcharge in the fare amount at the price display for the specific routing.
Fields Description:
Dates From /To :
Dates where surcharge is applicable. Week-end surcharge apply on total trip.
In Webfares, at end of fare lines, dates from and to are copied over from fare line to faciliate
information input. If no other information is provided, record is not created.
Surcharge ($) :
Total week-end surcharge amount (for outbound and inbound).
Days out/in :
Days of the week when surcharge is applicable outbound and/or inbound.
Key information: Date from/to
1.1.3 Taxes:
This table is used to enter ‘estimated taxes’ that can be show on the fares display in the booking
engine. It can be done manually or using the Import tax utility (see section 5.4)
In the booking engine, If ever the GDS can not provide the tax, the system will use the amount
manually entered and insert it in the tax amount in the PNR.
Fields description:
Tax Code : Tax code, name to identify tax
For Worldspan only, If you use the tax code OVER, the system
will override the GDS taxes with this tax amount.
Tax : Tax amount ( if > 1) or tax percentage (if < 1)
If the tax amount is smaller than 1, the system will consider it a percentage
and calculate the estimated taxes using the % on the net fare.
Key information: Tax code
1.1.4 ADVP:
This field is used for creating ticketing rules and advance purchase based on departure and
reservation dates required by your airline contract. If you are loading a COMM GRID contract, you
don't have to enter data in this field. But if you wish to load ADVP data for COMM GRID contracts,
your data will overwrite the GDS input.
Before: Means ‘before departure’ (for ADVP and TKT deadline)
After: Means ‘after reservation’ (for TKT deadline)
99 in ‘After’ fields means immediate (for immediate ticketing) and can only be used in 'After' fields.
Booking engine will use the 'Before' fields to validate advance purchase requirements. BE will use
the 'Before' AND 'After' fields to get the ticketing deadline (and option date)
Example:
If reservation is made more than 21 days before departure tkt must be issued at least 21 days
prior.
If reservation is within 21 days prior departure tkt must be issue 7 days after reservation no later
than 14 days before departure.
If within 14 days before departure tkt must be issued 72hour after reservation.
If reservation is within 7 days of departure tkt must be issued same day.
Before1: 21
After1: 7
Before2: 14
After2: 3
Before3: 7
After3: 99
Before4:
On the booking engine you will have (in rules) the following text (if nothing entered in ADVP text):
1. If reservation is made between 21 and 14 day(s) before departure
Tkt must be issued within 7 day(s) of reservation
2. If reservation is made between 13 and 7 day(s) before departure
Tkt must be issued within 3 day(s) of reservation
3. If reservation is made 7 day(s) before departure
Tkt must be issued same day as reservation
Whichever comes first
Special case:
Cannot be booked more than 120 days prior departure.
For this case you must leave the BEFORE 1 and AFTER 1 blank and put in the BEFORE 2 the
number of days 120. The After field must contain a value.
Before1: 0
After1: 0
Before2: 120
After2: 7
Before3:
After3:
Before4:
ADVP text:
To enter your own ADVP text that you which to display through the booking engine instead of the
pre-formated text automatically provided.
More information on Advance purchase, Ticket deadline, Option date and Time limit
Advance purchase requirements:
- System uses the Before departure fields in the ADVP table to determine if fare meets the advance
purchase requirement and therefore should be displayed or not on the booking engine.
Option date and TKT Deadline:
Step 1 : ticket deadline
- System uses both the Before departure and After reservation fields in the ADVP table to calculate
the ticket deadline.
- System will make sure that ticket deadline date does not fall on a week-end (SAT or SUN) or a
Holiday (from HOLIDAY table) table in order to ensure that ticketing departement is Open on that
date.
- System will compare it to ticket deadline date in TICKET table (related to fare) and keep the most
restrictive.
The result is inserted in PNR (if required)
ex: 10.H-OP. TKT DEAD/20031204
Step 2 : option date
- System will calculate an option date using the 'default option days' in the CONSOLIDATOR INFO
table ((for example, 3 means option date is 3 days After reservation)
- System will compare it to Ticket deadline from Step 1 and keep the most restrictive.
- System will check the current time versus 'cut-off time' in CONSOLIDATOT INFO.
If current time is After cut-off time, system will add 1 to current date to calculate the option date.
FOR SAME DAY DEPARTURES:
If current time is After cut-off time, bookings AND payments are NOT ALLOWED.
At time of reservation, the agent wil get the following message:
“Due to advance purchase requirement, your ticket must be issued today. To ensure that
(Consolidator's Name) can issue the ticket in time, you must call (Consolidator's Name) to apply
payment”.
At time of payment (for already made reservations), payment button will not be displayed on the
booking engine.
The result is displayed in the booking engine at time of booking and in the PNR (if required)
ex: 1.TL2300 /04DEC-2 /OPTIONDATEIS04DEC
Time Limit:
There are 2 settings (that can be changed only by Openfares) for the time limits. They are usually
set the following way:
Expire hour: 10pm
Same day expire hour: 5am (for same day departure)
For any reservations (other than same day departures):
If departure date is > option date, Time limit in the PNR will be 10pm (Expire hour).
If departure date is = option date, Time limit in PNR will be departure time minus 2 hours.
FOR SAME DAY DEPARTURES:
If departure time is > or = 5am (Same day expire hour), booking is permitted and TIME LIMIT is
set to 5am (Same day expire hour).
If departure time is < 5am (Same day expire hour), booking is not possible. Agent will get the
following message:
"It is possible that not all segments have been booked, this reservation was cancelled, plese try
again."
==>The Same day expire hour should be the same as the cut-off time if you want to allow same
day departure bookings. By setting it at 5am, no reservations can be done throught the Web for
same day departures.
Example:
Current date and time: DEC 1, 10 am
Default Option Days (In consolidator info) : 3
Cut-off time: 15h00
Expire hour: 10 pm
Same day expire hour: 5am
ADVP:
Before : 0
After: 7
Before: 10
After: 3
Before: 3
Departure date and time: DEC 12, 19h00 pm
We are 12 days before departure so Advance purchase requirements are respected therefore, fare
will be offered. (In this ADVP case, system will not allow reservations on for les than 3 days before
departure)
Departure DEC 12 is in 12 days so it is between 0 (0 can be interpreted as 365 days) and 10 days
Before departure. System will use the 7 days after reservation or 10 days before departure,
whichever comes first.
7 days After reservation is DEC 8
10 days Before departure is DEC 10
DEC 8 is the most restrictive (if December 8 was a Saturday, system would back up to DEC 7)
==> DEC 8 is the TKT DEADLINE
Option date using the 3 days after reservation in consolidator info is DEC 4. (DEC 1 + 3 days)
DEC 4 is more restrictive than DEC 8
==> DEC 4 is the OPTION DATE
Note: If we are December 1st at 20h00 and Cut-off time is 15H00, system would considerer that
we are December 2 (because ticketing dept. closed for Dec 1) therefore, option date would be DEC
5.
==> TIME LIMIT is 22h00 (because departure date is greather dans option date)
1.1.5 Ticket: Ticketing information.
Fields description:
Tkt deadline:
Ticketing deadline, will be taken considered for option date and ticketing deadline if more restrictive
than result obtained using ADVP table. See appendix 4 for more information.
Last return:
Last return date allowed, prices will not be displayed when returned is further than last return.
1.1.6 Routing:
Valid routing(s) for the fare. This will determine the availability results in your booking engine(s)
For NETS, there are 2 possible solutions for routings:
1- Nothing, no routings at all
2- Specify the valid routings, with or without VIA POINT(s)
For Commission grids (for commission overrides or private fares), there are 3 possible solutions:
1- Nothing, no routings at all:
3- Use of GDS or GDSSTRICT to retrieve routings in GDS rules
1- Nothing, no routings at all
In that case, we will accept any flight combinations returned by the GDS as long as all segments are
on the carrier specified in the Airline field (or on one of the two carriers if it is 4 letter carrier).
Ex. contract (ACLH) or (ACYY) were YY means any carrier.
You must first determine if:
a) a 'point to point' availability search is suffisant to retrieve the proper availability results
(using provided origin and destination only).
If so, you can enter the routings WITHOUT VIA POINT(s).
System uses the AIRLINE of CONTRACT for availability search and offers only the results that match
the provided routings. Example for a request from YUL to LAX carrier UA routing AC;YVR;UA via
point empty
--> System queries the GDS using YUL to LAX with UA and display only results that match
with the provided routing(s), AC;YVR;UA in this case.
b) a 'by segment' availability search is required to retrieve the proper availability results.
If so, you must enter the routings WITH VIA POINT(s).
System uses the AIRLINE from the ROUTING at the VIA POINT(s) to perform 'by segment'
search(es) in the GDS (not the airline that is specified at CONTRACT).
Example for a request from YUL to LAX carrier UA routing AC;YVR;UA via point YVR
--> System queries the GDS using YUL to YVR with AC AND YVR to LAX with UA, combine results
and displays the ones that match with the provided routing(s), AC;YVR;UA in this case
To restrict code shares within a flight segment:
If you want to only restrict code shares on a portion of the routing it would be done the following
way:
AC;YVR;AC(YY*);HKG;AC(YY*) --[ means no code share flights permitted except for domestic
segment
AC;YVR;AC(CX*);HKG;AC(YY*) --[ means code share are permitted on domestic portion
code shares are restricted between YVR and HKG on AC flights operated by CX
no code share flights permitted between HKG and final destination
You can enter more if separated by +
AC;YVR;AC(CX*+AA*);HKG;AC(YY*)
3- Use of GDS or GDSSTRICT to retrieve routings in GDS rules:
Before using this function, you must first:
a) make sure that the airline did load the routings in the GDS rules
b) check if availability search requires VIA points (for 'by segment' search)
Fields description :
Routing :
a) Routing description when specific routes must be followed
- The origin and final destination must never be part of the routing’s information.
- If Inbound routing is the same as outbound (but reverse), you must NOT enter anything in the
Inbound routing.
- You can specify Permitted or Restricted flights per segment inside the routing information and the
‘surplus’ amount related to the permitted flights.
- It is best to use city codes in Routings and Via points instead of airport codes when all city related
airports are allowed.
Routing Format: airline code 1/airline code 2/etc...;City or Airport code 1/City or Airport code
2/etc...; airline code 1/airline code 2/etc...;etc...
Example 1: (with multiple airlines and routes)
AC/LH;YYZ;AC;LAX/SFO/YVR;SQ;SIN;CX
Example 2: (with ZZZ option)
routing: AC;ZZZ;AC class: *;Y (on a V class fare line)
The booking engine will allow AC to any city in V class then AC to final destination in Y class.
This way, you do not have to enter all the transiting city and the class will be respect by the
booking engine.
--> ZZZ can not be used if the transiting cities must be used as VIA POINTS to retrieve availability
Example 3: You can specify Permitted or Restricted flights per segment inside the routing
information along with a ‘surplus’ amount related to those flights.
- If permitted/restricted flights apply for both inbound and outbound segment, format is the
following: AC(R0152-0156);ORD;UA
- If permitted or restricted flights applies only for outbound, the format is the following:
AC(R0152-0156-O);ORD;UA
- If permitted or restricted flights applies only for Inbound, the format is the following:
AC(R0152-0156-I);ORD;UA
So, In ALL cases, It must always be in the OUTBOUND routing field.
Other examples when more than one series with additionnal surcharges:
AC;YYZ;AC;LAX/SFO/YVR;SQ(P0094-0094S50,P0001-0093S20);SIN;CX
Means that only flight SQ0094 is permitted between LAX/SFO/YVR and SIN for an additional amount
of 50$ or flights SQ0001 to 0093 are permitted for an additional amount of 20$
AC;YYZ;AC;LAX/SFO/YVR;SQ(R0001-0099,R1000-1000);SIN;CX
Means that flights SQ0001 to 0099 and SQ 1000 are restricted between LAX/SFO/YVR and SIN.
IMPORTANT:
- In excel, because it is a coma delimited file, you must replace the , (coma) by the + (plus sign).
AC;YYZ;AC;LAX/SFO/YVR;SQ(P0094-0094S50+P0001-0093S20);SIN;CX
b) GDS or GDSSTRICT (for commission grids only)
GDS: System will use the routings provided in the GDS rules and decompose them for all the
possibilities. For example:
If routing in GDS are LAX-FRA/GVA-PAR we decompose the them to create all the possibilities:
LAX-LX-PAR
LAX-LX-FRA-LX-PAR
LAX-LX-GVA-LX-PAR
GDSSTRICT: System will use the routings provided in the GDS rules 'as is' (therefore we will not
decompose them). Some airlines already give ALL the possibilities (SQ for example). Decomposing
was simply creating too many possibilities.
For example: If routing is LAX-FRA/GVA-PAR we will not decompose, therefore, use the following
possibilities:
LAX-LX-FRA-LX-PAR
LAX-LX-GVA-LX-PAR
Via point(s) also works in pair with the GDS and GDSSTRICT option.
If you need to use specific classes for each feeder, they must be specified in a different format.
Class:
This column allows you to specify the class of services(s) to use for each of the routing segments.
Class format works in combination of Routing format.
You must specify the classe(s) for each airline in the routings.
a) Using routings (with or without via points):
- If all the classes are the same as the fare line, you do not have to fill it out.
- If you do put the classes, you have to put it for the each flight segment and for all routings.
* The star will be replaced by the main class.
Examples for routing AC;YYZ;AC/MX;MEX;AC/MX on L class fare line
EX 1: Class L;L/V;L/V or *;*/V;*/V -- means to use L class on the AC flights and V class on the MX
flights
EX 2: Class *;*;* or *;*/*;*/* or blank -- means to use L class all the way for both AC and MX
There can be as many classes as required for a specific airline, separated by /
- If you have multiple (and different) classes for more than 1 airline on same flight segment, you
will have to
separate the routings accordingly.
For instance, if for routing AC;YYZ;AC/MX you can use S and T class on AC from YYZ to final dest.
OR U and V class on MX for same segment, you will need to have the followin information:
routing: AC;YYZ;AC class: *;S/T
routing: AC;YYZ;MX class: *;U/V
If you keep only 1 routing AC;YYZ;AC/MX and indicate the classes the following way *;S/T/U/V,
system will not be able to determine wich classes belong to wich airline.
b) Using GDS or GDSSTRICT in routing:
If you need to use specific classes for each feeder, they must be specified in the following format:
Mainclass/feederclasses/feederclasses/etc;Mainclass/feederclasses/feeder/classes/etc.;etc.
The star * can be used for the main class if the feeder classes must be the same as the main class
Examples:
SQ Contrat, whatever the main class (*), AC must be in Q or V (ACQV), AA in Y (AAY),
US in same classe as SQ (nothing to specify, system will know to use same class as main class)
Format would be : */ACQV/AAY
If the feeders classes depends on the main class, then you must specify the information for each of
the main classes. SQ Contract, using B class - AC must be in V (B/ACV), using W class - AC must be
in K (W/ACK)
Format would be : B/ACV;W/ACK
Of course, the mix of both could also be done: */AAY;W/ACK;C/ACJ
Stopover:
Stopover information related to routing.
This field allows to identify per routing, information on
a) Stopovers (S)
b) Via surcharge (V)
c) Overnight (O)
d) Fare basis replacement codes (FB)
The format is the following: Airport(Samounttypesign)(Vamounttype)(Otype);FB(SFO/LAX);
Airport(Samounttypesign)(Vamounttype)(Otype); etc
Example: SFO(S100B+)(V50);LAX(S0B)(V15B);YVR(OY);FB(LAX/SFO/YVR)
a) Stopovers (S)
amount: amount related to the stop over (enter 0 if always free)
type: is either Outbound, Inbound, Both or Either
sign: if a plus sign is present, surcharge is ALWAYS applicable, even if one stop is FREE
ex: SFO(S100B+)
Stopover works in relation with nb.stops to control the total number of stops and the free stops.
Stopover fees will be added to fare when request WITH STOPOVER is used in the B2B booking
engine.
b) Via surcharge (V)
amount: amount charged if travel is via the airport code (if blank means free).
type: is either Outbound, Inbound, Both or Blank means Either
SFO(V50B) will charge $50 outbound if via SFO AND $50 inbound if via SFO
SFO(V50O) will charge $50 outbound only if via SFO
SFO(V50I) will charge $50 inbound only if via SFO
SFO(V50) will charge $50 total (weather via SFO is Outbound and/or Inbound)
c) Overnight (O)
type: type = N
ex: YVR(ON)
If nothing specified, system will look for overnight flights ONLY if there are NO flight possibilities
without an overnight
(regardless of space left).
You should use the Overnight = N if you do not want the system to look for overnight flights when
there are no other possibilities.
In a futur release, Overnight = Y that will mean to look for overnight flights even if there are flights
without overnight but no space left on them.
d) fare basis replacement codes (FB)
If you have created your fares with ZZZ in the fare basis because it needs to be replaced by
an airport code, according to selected routing, here is how to do it:
In you fares you will have the fare basis with the ZZZ were ZZZ should be replaced.
ex: ALZZZ05C
In the stopover field, you would identify the values to replace the ZZZ
ex: FB(LAX/SFO)
The booking engine will react the following way:
- if selected routing is through LAX, fare basis will become ALLAX05C
- if selected routing is through SFO, fare basis will become ALSFO05C
GENERAL EXAMPLES:
A) Contract with Cathay Pacific via HKG to Sydney Australia.
The stopover rules in the contract indicate:
1 stop is permitted in HKG on the outbound at a cost of $135.
1 stop is permitted in HKG on the inbound and it is FREE.
1 free stopover permitted in YYZ , additional stop add $100net.
In Webfares, the Outbound stopover field would then contain:
HKG(S135O+);HKG(S0I+);YYZ(S100B)
- charge $135 on Outbound stopover to HKG and the + means do not count it as free stop.
- charge $0 for Inbound stopover to HKG and the + means do not count it as free stop.
- Stopover in YYZ is permitted Both direction at a charge of 100.00$
In the nb. Stop field you need to enter 41 meaning 4 stopovers for total trip are permitted and 1 of
them is free.
Note that the we do not consider the stopovers that have the + indicator in the nb.free stops so it is
applicable only for the YYZ stops.
So here are the test results in the booking engine:
B) The first stop $100, second stop $200 in TPE.
TPE(S100B);TPE(S200B)
Via point:
Indicates where you want to break the routing and make some 'by segment' search in the GDS.
Via point(s) determine how availability research is GDS will be performed.
Via points are used in cases where 'Direct Access' of contract carrier does not show the other carrier
specified in the routing. You can have more than one via point per routing and the airport code or
city code provided must be part of the routing it relates to.
If for example you have YYZ;AC;LAX;SQ;SIN with a via point LAX it will search for all the YYZ-LAX
flights with AC and all the LAX-SIN flights with SQ that have at least 90 minutes connecting time
and display them. If you would go in Sabre and search a YYZ-SIN with AC, you will not get the SQ
flights. If multiple via points, they must be separated by ; and entered in SAME order as in routing.
ex:via point SFO;LAX;YVR for a routing such as YYZ;AC;LAX/SFO/YVR;SQ;SIN
NOTES:
VIA points were primarily designed to treat contracts where you have to break the itinerary because
the full itinerary does not show in the GDS. So they are most commonly used in the case of multiairlines contracts.
They can still be used on a single airline contract but in that case the VIA point must be a hub for
the airline. You should not have a via point between 2 airports that requires you to sell married
flights.
Routings Display on the B2B Booking engine: Routings can be display the 2 following ways in the
rules:
Option 1: YYZ with AC in V to LAX with AC in V to FINAL DESTINATION
Option 2: YYZ AC/V LAX AC/V FINAL DESTINATION*
* You must contact Openfares if you which the second option, we would have to change your
custom file.
When Using GDS (or GDSSTRICT) routings:
- if nothing specified, system will generate via point everytime there is a change of airline, therefore,
do a by segment availability search for all the routings.
- if you do not want the system to generate a via point when there is a change of airline
(Ex. NWKL that needs to be married flights), you must put value NIL in via point.
System will then not perform a by segment search (see example below)
- If you want the system only SPECIFIC via points, you can enter them separated by ;
Format examples: SFO;LAX or NIL or blank
Example with GDS routing showing the importance of VIA POINT information:
For: FDSAOCHI/UA@WLXPEX
LR*1
GDS will provide the following routings:
SAO-MIA-WAS/ORL/TPA-NYC/EWR/PHL/CLT-CHI
SAO-MIA-WAS/ORL/TPA-CHI
SAO-MIA-ORL-CHI
SAO-MIA-ORL-CHI
SAO-MIA-WAS-CHI
SAO-CHI
SAO(YY)RIO-MIA-WAS/ORL/TPA-NYC/EWR/PHL/CLT-CHI
SAO(YY)RIO-MIA-WAS/ORL/TPA-CHI
SAO(YY)RIO-MIA-ORL-CHI
SAO(YY)RIO-MIA-WAS-CHI
SAO(YY)RIO-CHI
SAO-MIA-ORL-CHI
SAO-MIA-WAS-CHI
SAO-CHI
If NO VIA POINT, for the routings with airline (YY), system will generate a by SEGMENT search for
each segment at change of airline. This is generating over 2000 possibilities, therefore causing the
system to take a lot of ressources and time out (after the maximum of 2 minutes)
By putting NIL in the VIA POINT, it indicates to the system NOT TO GENERATE a SEGMENT by
SEGMENT search at change of airline. In this particular case, it is not necessary to use via points to
get proper availability. That way, system provides availability in a few seconds.
1.1.7 Open Jaws:
To allow Open Jaw and/or Mix of classes.
Can only be linked to a specific fare line. Regardless of the contract, all fare lines with matching
zone and type from the open jaw rules will mix together if they are attached to the same airline in
the contract top information.
There is an exception for AC, ACYY or ACLH were they will mix if they have the same openjaw rule.
For directional flights, the fares will mix only within the same contract.
Fields description:
Zone :
To attach an open jaw zone number (01 to 99) to the fare line it is related to.
Zone is determined by the consolidator, you maintain your own list.
make sure you use a 2 digit code.
Type :
To attach an open jaw type (AA to ZZ) to the fare line it is related to.
Type is determined by the consolidator, you maintain your own list.
==> For a specific fare line, the Zone and the Type is always the same because it determine the
open jaw zone of the fare line. The open jaw type is totally independent of the fare Type.
make sure you use a 2 alpha code.
With zone :
To identify which open jaw zone (01 to 99) the fare line can be mixed with.
make sure you use a 2 digit code.
With type :
To identify which open jaw type (AA to ZZ) the fare line can be mixed with.
make sure you use a 2 alpha code.
Ratio :
Will determine amount percentage related to open jaw.
50 means half the price of each open jaw segment.
100 means the price of the most expensive segment.
0 means the price of the outbound segment.
Most restrictive Min/max stay requirements is validated by the Booking engine.
Mix classes :
To indicate which classes can be mixed together. If blank, system mixes all the classes.
Example: J;K
For instance, if you have zone 2 with zone 2 and zone 2 as J;K;L classes but you want to mix only
J&K together in order to get JJ or JK or KJ you would then enter J;K in mix classes
Applicable on :
Identifies if open jaw is applicable on:
D for
O for
B for
E for
M for
destination (YUL-YVR, YYC-YUL)
Origin (YUL-YVR, YVR-YYZ)
Both (YUL-YVR, YYC-YYZ)
Either (Origine OR Destination)
Mix classes only, no openjaws
If left blank, default value is D.
Mandatory information (key) : Zone, Type , With zone, With type
1.1.8 Rest. Flights:
Restricted or permitted flight numbers and classes. Will apply for all routings.
If permitted or restricted flights must be identified by segment, you can specify them in the routing
itself. (see section 1.1.6)
Fields description:
Airline :
2 digits airline code.
Flight from/to :
Flight numbers from and to
Restricted/Permitted :
Indicates if the flight series is restricted or permitted.
If you have the following case:
Restricted flights 1000 to 2000 for the whole contract except 1 fare line. Usually, the global spec
should apply to all the fare lines of the contract but you could do the following:
Enter a global specification for restricted flights 1000 to 2000
Enter a specification for restricted flights 9999 to 9999 on the exceptional fare line.
That way, because the system uses the specifications instead of the global specifications it will
restrict only flight 9999 which doesn’t exist and therefore, no restrictions on flights 1000 to 2000.
To restrict code shares for a specific AIRLINE or ALL airlines, you will enter * sign that
represents the range in 'from' and 'to' fields in the restricted flights table for that specific airline.
Example:
Airline from to restricted/permitted
CX * * restricted (for a specific airline)
YY * * restricted (for ALL airlines)
Class :
You can indicate classes in restricted/permitted flights. What it means is that for all fares that would
require specific routings and do not require Via points, the routings could be omitted and replaced
by permitted flights with the specific classes.
1.1.9 Connectors
To indicate with which airlines the Connecting fares, Add on or Side trips can be offered and how
many days off connecting time is allowed. This table is used only when fare type CT, AT, AD or ST
is entered.
Fields description:
Airline(s) :
The connectors fares will be allowed only with flights of the specified airlines. If no airlines are
specified, connectors fares can be matched with any airline.
Example: AC;DL
Days :
Numbers of days allowed between connecting flights.
1.1.10 Rules
Text rules that will be displayed in the booking engine when agent clicks on RULES button for NEGO
fares. For commission grids, system displays uses only the fields in RED along with GDS rules.
Ticket designator, Endorsement and Tour code will be presented only to internal agents.
Changes 1: Changes specifications.
Penalty: Penalty information.
*Name change: amount to charge for name change
*Other change before dep.: amount to charge for changes (other than name) before departure
*Other change after dep.: amount to charge for changes (other than name) after departure
*These fields are not yet linked to the booking engine.
Child fare: The child fare (percentage).
Infant fare: The Infant fare (percentage).
Senior Discount : The applicable senior discount.
Youth discount: The applicable Youth discount.
Tkt designator: Ticket designator. Mostly for use of ticketing department. Is not displayed to
external users.
Endorsement: Information required in Endorsement box of ticket. Is not displayed to external
users.
Option days: Number of days prior to departure an option can be kept.
Special Taxes: Special taxes, mostly for European clients.
Stopover: Are you allowed Stopovers for this fare.
Open Return: Are you allowed Open return for this fare.
Open Jaw: Are open Jaws permitted on this fare.
One-Way: Is this fare a one way or round trip.
Tour Code: Is their a specific tour code. Is not displayed to external users.
Mix class: To identify if classes can be mixed.
E-ticket: Electronic ticketing information.
UNMR: Unaccompanied Minor information.
Additional Comments:ts:
Free Flow of additional comments.
If created directly in Webfares, you must type ‘enter’ to indicate that it is the end of the first
comment line. First comment line will be shown at fares display page (for both NEGO and
COMMISSION GRID fares) under the fare line (or remark column) as well as in the rules page.
Routing Remarks:
Free Flow of additonnal routing options.
IMPORTANT:
Do not use the ',', ‘;’, ‘:’ ‘'’ and ‘!’ anywhere in the rules. It is a special character that we are using
to split the fields in the export or import functionalities or that are reserved in programming.
1.1.11 Black Out :
Black out dates.
From/to :
Black out dates from and to.
Out/In :
You can enter B for both (Outbound and Inbound)
O for Outbound
I for Inbound
Trick : If ‘global’ black-out dates do not apply to a specific fare line(s), you can enter the black-out
dates at contract level specs and for the exception(s), enter past black-out dates at fare line level
specs.
1.1.12 DOW:
Days of the weeks where fares are applicable (when they fly). If left blank, system will assume all
days of the week. If you do put specific days of the week (example 134), fares will not be displayed
when a request is done for days other than 134. The disadvantage of this is that agents are not
sure if you do have the fare or not. Perhaps it is best not the specify the days of the week and let
the agent discover at availability request that there are no flights on those days (and look at the
flight schedule).
This is not to determine the week-end fares and days (see Week-end surcharge)
This will be used in special cases, for example when class of service is determined by day of week.
Example:
T class $300.00 good for
V class $357.00 good for
K class $326.00 good for
Q class $386.00 good for
midweek: DOW out = 23456 DOW in = 1237
weekend: DOW out = 17 DOW in = 456
midweek: DOW out = 23456 DOW in = 1237
weekend: DOW out = 17 DOW in = 456
You would have to build 4 fare lines with DOW in each (outbound and inbound).
Therefore the following combinations would have to work:
T-T MW-MW
T-V MW-WE
T-K MW-MW
T-Q MW-WE
V-V WE-WE
V-T WE-MW
V-K WE-MW
V-Q WE-WE
K-K MW-MW
K-T MW-MW
K-V MW-WE
K-Q MW-WE
Q-Q WE-WE
Q-T WE-MW
Q-V WE-WE
Q-K WE-MW
1.1.13 Fare Applicability:
This table is used to link the eligibility requirements on fares. Eligibility requirments can be displayed on the
B2B request page if selected in the co-branding module.
Type is A (for Age), D (for Date) or T (for text)
Example: T (for text) TCAN the code you chose to create for your own free flow text. In this example your text
is:
"Canadian Passport Holders Only"
The example "TCAN" code created in the Eligibilty table in General info will have to be entered in the contract
the fares apply to.
You choose the code you created from the dropdown menu to the left of the Fare Applicabililty screen. The
Fare Appl. button exists in Webfares in all 3 levels of specifications. Level1 (fare line level), Level2 (page level),
Level3 (contract level) for Nego and Comm. Grid contracts.
Fare Applicabililty fields exist in Nego and Comm Grid 110 and 113 excel sheets as well. They are in 3 columns
in excel sheets. Column DD/DE/DF in 110 column version, column DF/DG/DH in 113 column version. If you
have multiple eligibility codes for your excel sheet, the fields must be separated with & sign.
Example: If you had:
ISIC card holders with age requirment of 18 and
BBB code for the date requirment of 15/11/08 and
TCAN code for your own text requirment of "Canadian passport holders only"
In your 110 version excel you would be entering:
Column DD Column DE Column DF
ISIC&BBBB&TCAN A&D&T 18&15/11/08&Canadian passport holders only
To be able to use this feature you have to turn it on in your Co-branding module by check marking
"Let users enter eligibility"
1.2 Comm. Grids
The Commission Grids option is used to create commission grids that will enable your booking engine to retrieve:
- Published fares and apply your commission override(s)
- Private fares (ATPCO fares loaded in GDS) and apply your mark-up
What determines that the commission grid is for Private Fares is the fact that fare type will be equal to PF.
If you have this module enabled (commission grids = implicit in co-branding module), your Web Booking Engine will
automatically retrieve published or private fares for which commission grids have been created in WEBFARES, apply
commission and/or mark-up and display the information through the booking engine.
When more than 1 commission grid applies for a specific gateway or destination, system will use the following order
to determine priority:
gateway/destination
gateway/zone
zone/destination
zone/zone
gateway/YYY
YYY/destination
YYY/YYY
If for instance you have the following commission grids:
YUL/PAR
YUL/DEUROPE (that contains PAR)
YUL/YYY (where YYY means the world)
for a YUL to PAR, system will use the specific YUL to PAR commission grid.
That way, it is possible to create exceptions.
It is also possible to load commission grids using an excel file (see Import menu, Excel Com. option)
*** Please note "Netfaresonline" doesn't accept YYY code, therefore contract loaded with YYY to NFO will not display
fares.
IMPORTANT:
These fares are automatically retrieved when agent asks for NEGOTIATED fares.
Do not get confused with the 'WITH PUBLISHED' option. The WITH PUBLISHED option will simply retrieve the best
'PURE' published fares directly in the GDS using Super $BB for Galileo, Trip Search for Sabre and Power Shopper for
Worldspan. The availability results are displayed using 'green dots' because these commands provides only 'available'
fares.
For GALILEO, there is an option to apply the commissions grids on those 'PURE' published fares.
You must contact Openfares to have this set ON.
For Private Fares:
You MUST enter
a) Validity dates (from and to) - does not need to be broken down in seasonalities, system will know which basis
to display according to requested dates
b) PF in the fare TYPE to indicate that this is for Private fares in the GDS - no need to indicate anything else,
system knows to then select only private fares and apply your mark-up. Specific classes of basis should be indicated
only if a different mark-up is applicable.
c) The applicable mark-up
If you have for example:
PF $30
PF Q $40
PF QLXSV2 $50
System will know to first look for fare basis exceptions and then class exceptions to pick up the proper markup.
You can also use wild cards and exclusions.
To determine the COST your can fill out the %override (if you are given and extra reduction on private fares)
To determine the SELL, you can fill out the mark-up (not agency $ or %, those are for commission overrides only)
COST = Private fare minus %override (in % or $) - If $, must be indicated with minus sign (-30)
SELL = Cost + mark-up ($) or (%) - an amount lower than one indicates a percentage mark-up (.05)
System gets the private fare from your GDS as your "COST". To create sell you need to enter a Mark up.
Mark up as dollar amount (EX 1)
Mark up as% amount (EX 2)
If you have further discount from the private fares; you can enter your discount in Override% field to adjust your
cost
Mark up as dollar with Override entered as dollar in Override % field ( EX 3)
Markup as % with Override entered as % in Override % field ( EX 4)
** A minus figure ( -30) in this column denotes dollar amount to be taken off, where as a postive figure (10)
denotes % to be taken off For Commission Overrides:
You MUST enter EITHER the fare type (YY for all fare types) or class or fare basis.
You also fill out the %override and (agency % OR agency $ )
To determine the COST you can fill out the %IATA and/or %override
To determine the SELL, you can fill out the agency $ and/or agency %
COST = Published fare minus %Iata minus %override(s)
SELL = Published fare minus agency % (when agency mark up in %) or COST + agency $
(when agency mark-up in $)
System gets the pub fare from your GDS . To create "sell" amount, you need to enter either agency$ or
agency%. "Sell" amount based on % off Pub fare ( EX 1)
"Sell" amount based on adding Agency$ to Pub fare ( EX 2)
To create a "sell" amount , when you have either IATA% or Overrride% or both:
"Sell" amount based on adding Agency $ after both IATA% and Override % ( EX 3)
"Sell" amount based on adding Agency$ after Override % ( EX 4)
Special cases: If you have "1" in Agency$ field; SELL = COST (Whatever your cost might be.) (EX 5)
If you have "0" in Agency$ field; SELL = GROSS (Gross Pure Pub fare from the GDS.) (EX 6)
For both:
- If fare basis is specified, you need only to enter the mid-week fare basis (with the x)
System will know to replace the X by W if week-end fare applies, once basis is inserted in PNR.
- If the fare must be booked in a specific class (other than the one specified) only then you fill out the 'Book in class'
- If week-end days are different than OUT 567 IN 567, you must fill out the Week-end table with the proper days
OUT and IN. Amount is always retrieved in the GDS so you can leave it at 0.
- If specific fare basis apply for specific days of the week, you must fill out the DOW table.
For example (UA PF contract)
Fares basis VHXSP middweek (dow out = 1234//dow in = 1234)
Fare Basis VHWSP weekend (dow out = 57 // dow in = 57)
Fare basis VHSJP Saturday (dow out = 6 dow in = 6)
There should be the following comm grid entry:
PF ----VHXSP (DOW out 123457 in 123457 )*
PF ----VHSJP (DOW out 6 in 6)
* no need to enter the week-end basis, system will do it automatically
Also, in order to mix the fares (the saturday basis with others mid-week and week-end fare basis), OPEN JAW rules
must be entered.
For SCREEN SCRAPE of WEB FARES:
For Web Fares such as AC (www.aircanada.com), WS (www.westjet.com), etc...you must create a commission grid
with proper origin/destinations and have OFWEBSS in fare basis.
Openfare must set this ON for you and you need to provide a user/pass for each of those websites.
For each GDS:
For Sabre, Galileo and Amadeus, the following rules are automatically validated:
-
Seasons
Min/Max and mandatory night stay
ADVP
Ticket deadline
Last return
Week-ends
--> black-out dates need to be loaded in commission grids, if you want them to be validated at fare display.
For Worldspan, the following rules are automatically validated:
-
Seasons
Min/Max stay
Black-out dates
ADVP
DOW
Ticket deadline
Last return
Week-ends
For ALL GDS:
- The booking engine will return valid fares but not availability restrictions so, you still must load restricted flights
and routings in the commission grids if required
(mostly for private fares and seat sales)
- Text rules are pick up from the GDS or from Webfares (option per contract)
- In both cases, you can enter your own change and penalty in rules table, the system will display your change and
penalty fees along with the ones from the GDS.
(So, you can write someothing like: "As per published + $40".
There are 3 levels of specification tables:
Level 1 (D) Spec. button at end of commission grid line.
Each fare commission grid line can have its own specifications.
Takes priority on Global and contract specifications (level 2 and 3)
Level 2 (P) Global specification tables at bottom of commission grid screen.
The Global specifications will be related to the group of destinations specified on top of page. Takes priority on
contract specifications (level 3)
Level 3 (E) Spec. on top of page, beside contract identification.
The specifications will be related to all commission grids that have the same contract identification.
The * beside the specification table name indicates that the specification table contains information.
For each line, you must click on the 'save' or 'spec' button to register the information in the database OR click on
SAVE ALL to update the full page.
KEY INFORMATION (mandatory):
The system will not keep the information if you input duplicate key information.
While you input directly in Webfares, if you modify key information, system will create another record with the
different key.
You can modify Key information using Search Nego.
Key information in a fare line is:
Date from/Date to/Class/Book in class/Basis/Type/RT or OW indicator
Suggestion:
You should create your commission grid with Input Nego with only one line and save it. Then use the search
commission grid to continue the input. You will then be able to modify all information.
If you add a gateway or destination in a zone (using the Search zone), it will automatically be added in the top
information of your commission grid lines that are attached to the zone.
Order of data:
The system creates each commission grid line in the database with a line identification (number).
It attributes the line identification when you click on the spec or save at the right end of the fare line.
When you will use the Search commission grids, lines will be displayed sorted on the line identification. If you want to
make sure that the lines are in the same order they where created you must click on the spec or save at the end of
each fare line in the proper sequence.
Fields description:
#id :
Commission grid identification number (comm_grid_id).
Commission grids are created using :
(Gateway(s) OR Gateway Zone) AND (Destination(s) OR Destination Zone)
Gateway:
City of origin for which the commissions apply. If more than one gateway they must be separated buy ‘;’. You must
enter the gateway(s) or the zone.
Example: YUL;YYZ
If you enter YYY, it will mean the world!
(make sure you delete Airport code YYY if you plan on using this feature)
Dest:
City of destination for which the commissions apply. If more than one destination. They must be separated by ‘;’. You
must enter the destination(s) or the zone.
Example: YYC;YVR
If you enter YYY, it will mean the world!
(make sure you delete Airport code YYY if you plan on using this feature)
Zones:
Pre-determined zone identifying a group of city’s.
The gateway zone starts with a G
The destination zone starts with a D.
Airline:
The airline for which the commission grid applies.
Example: AC or YY or DLYY
-->If no routings are entered - system will use this airline(s) for availability search in the GDS and display all
available flights for this airline(s). If for example you have an AC contract that is code shared with more than one
airline (BA - AF - …), you can enter ACYY and specify the routings for each airlines in the routings table. In that case,
system will request availability using AC availability search in your GDS and display all the results for AC or any other
airline(s) through AC's availability search.
-->If routings are entered (WITH VIA POINTS) - system uses the airline from the routing at the VIA POINT(s) to
perform segment by segment search(es) in the GDS (and not the airline(s) specified here).
For example, routing AC;LON;BA with VIA POINT LON, system will query GDS the following way:
a) from origin to LON with AC
b) from LON to final destintion with BA
-->If routings are entered (WITHOUT VIA POINTS) - system will use this airline(s) for availability search and
display only the results that match the specifed routings.
-->If GDS or GDSSTRICT routing functionality is used, system will use this airline to retrieve the GDS routing. If
you have 2 ailrines, system will query the GDS using both airlines (ex: KLNW, system will query GDS for routings
using KL and using NW).
Once contract is imported in webfares, you must set up the AIRLINE information (if not already existing) in
Webfares/General info/Airline.
In search mode, the field name is a direct link to the Airline table.
Contract:
Contract name.
Many groups of gateways and destinations can be related to the same contract.
In search mode, the field name is a direct link to the contract table.
PARTICULARITIES:
If contract name ends with -SD it will be considered as a student fare commission grid contract (for commission
overrides OR Private fares).
If contract name ends with -CRP it will be considered as a corporate fare commission grid contract (for commission
overrides OR Private fares).
For WORLDSPAN:
If contract name ends with -JCB or -PFA, the passenger type at booking will be *JCB ou *PFA in order to do the
safety net correctly. If not, we use the default pax type *ADT
For each commission grid line:
Rep/del:
Repeat: The repeat button copies the information of the selected line onto the next line available.
You must change at least 1 key item of that new line (From/to, class, type, basis or ow/rt flag)
Make sure that you save your new line by clicking on the 'spec.' or 'save' button at end of line! System does not
copy over the specification tables. To do so, you can use the following buttons:
- Copy specs: To copy specs tables from 1 fare line (Id) to other(s)
or
- Copy rules: To copy only for Rules table from 1 fare line (Id) to other(s)
--> To indicate a series of fares id, you must enter it the following way:
100-110 (for lines 100 to 110)
--> To indicate specific line id(s), you must separate the numbers by a coma:
100,102 (for lines 100 and 102)
- Refresh: Click on refresh If you want the system to provide you with the fare line number (Id) of a new line.
Delete: The delete button is used to delete a fare line (only in search option). You must check mark the delete
button and click on 'save' at the end of the fare line.
id :
Commission grid line identification (comm_grid_det_id).
Used in copy rules and copy specs utilities.
To get the Id. while adding new lines in search mode, use the 'refresh' utility.
From/To :
From and to date of commission grid’s validity.
Format: YYYY/MM/DD or YY/MM/DD or YYYY-MM-DD or YY-MM-DD
-> Note that date format is different in Excel (it is DD/MM/YY or DD/MM/YYYY or DD-MM-YY or DD-MM-YYYY ) but
import program automatically converts them into the Webfares format.
--> Once contract is created you must indicate if Season/wk-end based on trans. segment (in CONTRACT table) along
with other contract information.
Min/Max:
--> required for Sabre because not validated at time of faring but only at time of booking.
Minimum and Maximum stay (number of nights) requirements.
Example : Min 1, Max 1Y (or 365)
Values can be in formats such as: 30 or 1M or 1Y
If you put 999 in minimum stay, the system will automatically use the mandatory nights to display minimum stay
(must be a number) in the following way:
Min: 999
Mandatory night stay : 5,6
Booking engine will display for minimum stay: Fri or Sat
Night (s) :
--> required for Sabre because not validated at time of faring but only at time of booking.
Determines if the minimum stay requires specific nights of stay over.
Values are number 1 to 7 or A to G for Monday through Sunday.
If you use numbers it will mean ‘OR’ and if you use letters it will mean ‘AND’.
Example:
5,6 means minimum stay OR mandatory nights (Friday or Saturday)
E,F means minimum stay AND mandatory nights (Friday and Saturday)
You can not use letters in mandatory nights combine with the 999 because the system will think it is 999 days and
the mandatory night(s).
Type :
Fare type selection criteria.
For Commission overrides on published fares:
To select published fares according to fare types:
YY= ALL of the types below (wild card)
YD= special economy (pay eco travel business.). If first character of fare basis is = D
YJ= business if first character of fare basis is = J or C
YF= first if first character of fare basis is = F
EX = the fare basis contains EE (ex: YEE6M).
AP = the fare basis contains AP (ex: MHXAP4M)
AB = the fare basis contains AB (ex: KHXAB2M)
SS = If non of the above it will be treated as a SS fare type.
For Private Fares:
Fare type MUST be equal to PF
Class :
Class of service selection criteria.
You will specify the classes if the overrides are applicable only on specific class of services of if they are different
from one class to another.
This is the fares main class of service. Connecting flights (feeders) classes are determined in the routing table when
they need to be different than the main class.
Example : Q
How to EXCLUDE some classes:
If you enter XXclass, system will exclude all the fares with the class that matches value after XX.
So, if you have the following commission grid line: fare type: YY class:XXQ
System will display all the fares except the Q class fares
Fare Basis :
Fare basis of midweek fare. You do not have to specify the week-end fare basis, if same but W instead of X. System
will know to replace the X by W if week-end fares apply once basis is inserted in PNR.
Ex: VLXART
How to EXCLUDE some fare basis:
If you enter XXXbasis, system will exclude all the fares with fare basis that matches the value after XXX.
So, if you have the following commission grid: fare type YY fare basis XXXT7E2CNR
System will display all the fares except the ones with the matching T7E2CNR fare basis.
How to select fares using WILD CARDS:
If fare basis starts with @@value, system will display all the fares with a fare basis that 'contains' the value after the
2 @@.
So, if you have the following commission grid lines:
1) fare type YY (override 10%)
2) fare basis @@QLS (override 20%)
All fares will use the 10% override except the one that have a fare basis that contains QLS (such as
QLSAL5,VSALEQLS, HKQLS3M) that will use the 20% override. Wild card value CAN NOT contain NUMBERS (only
alpha from A-Z)
IMPORTANT:
- If week-end days are different than OUT 567 IN 567, you must fill out the Week-end table.
- If specific fare basis apply for specific days of the week, you must fill out the DOW table.
For example (UA PF contract):
Fare basis VHXSP middweek (dow out = 1234//dow in = 1234)
Fare basis VHWSP weekend (dow out = 57 // dow in = 57)
Fare basis VHSJP Saturday (dow out = 6 dow in = 6)
There should be the following comm grid entry: Type Basis DOW table
PF VHXSP out 123457 in 123457*
PF VHSJP out 6 in 6
* no need to enter the week-end basis, system will do it automatically
In order to mix the fares (the saturday basis with others mid-week and week-end fare basis), OPEN JAW rules must
be entered.
For SCREEN SCRAPE of WEB FARES:
For Web Fares such as AC (www.aircanada.com), WS (www.westjet.com), etc...you must create a commission grid
with proper origin/destinations and have OFWEBSS in fare basis.
Openfare must set this ON for you and you need to provide a user/pass for each of those websites.
Book in class :
If the fare must be booked in a different class (other than the one specified by the class or basis) then, you fill out
the 'Book in class'.
Not used for Private fares.
Example : Q
IATA % :
Standard commission given by IATA to the consolidator. Will be deducted from fare to determine the cost.
Override %:
Commission override given by the airline to the consolidator. This a % field.
Ex: 15 will be considered as 15%
A minus figure ( -30) in this column denotes dollar amount to be taken off, where as a positive figure (10) denotes %
to be taken off Ex: -30 will be considered as 30$
Agency %:
Portion of the override that is given by the consolidator the agency in order to determine the Sell.
You must fill out EITHER the agency % or $
The agency % will be deducted from published fare to determine the sell.
--> This is not for PRIVATE FARES. Agency mark-up for pivate fares is indicated in mark-up field.
Ex: 10 means 10%
Sell calculation example: Published fare - agency % = Sell
Published fare - agency% --> SELL
$ 1000 - 10 --> $900
Agency $:
Agency mark-up in dollars for commission override fares. This is used if you want to add keep a mark-up amount
over your cost to determine the sell to the agency.
You must fill out EITHER the agency % or $
The agency $ will be added to the COST to determine the sell.
--> This is not for PRIVATE FARES. Agency mark-up for pivate fares is indicated in field mark-up
Ex: 50 means 50$
Sell calculation example: COST + agency $ = Sell
Published fare - override = % COST + agency$ --> SELL
$ 1000 - 10 = $900 - 50 --> $950
Cap :
When agency commission is in % this is to CAP the commission to a maximum amount.
Will be use to calculate the SELL fare.
Example: 60 (for $60.00)
If published is $1000, agency % = 10 (therefore 10 % of 1000$ = 100$), system would generate a
SELL of $900 (1000$ - 100$ = 900$)
If you cap it to 60$, system will generate the SELL of $940, using the the maximum amount of $60 commission.
Mrk-up :
Agency mark-up in dollars or percentage (if amount lower than 1) for Private fares.
The mark-up will be added (or divided) to the COST to determine the sell.
--> This is not for COMMISSION OVERRIDE fares. To be used for with PRIVATE FARES. (Agency mark-up for commission overrides is indicated as (agency %) or (agency $))
Ex:
50 means 50$
.95 means 5%
Sell calculation examples:
if $ (>1) COST + mark-up = Sell
if % (<1) COST / mark-up = sell
COST + mark-up --> SELL
$1000 + 50 ------->$1050
$1000 /.95 -------->$1053
C/C fees:
Credit card fees applicable to these fares.
These C/C fees will override the C/C fees entered in Consolidator info.
You can enter either 3 or 3.00 for dollars amount or .03 for percentage.
Chd:
Child fare, determined by a percentage of the net fare or specific amount.
Format:
75 means 75% - percentage on the net fare
blank field or 0 is considered as 100%, same as net adult.
Inf:
Infant fare, determined by a percentage of the net fare of specific amount.
Format:
10 means 10% - percentage on the net fare
blank field or 0 is considered as 0%, free or N/A
If infant selling fare is the same as net adult, you must enter 100
NOTE:
When using a percentage, Child and Infant fare is calculated using either the Adult Net or Sell fare, according to
option Child & infant on Sell or Net (S/N) in General info/Consolidator (section 3.1)
If on Net (N):
example :
Net: 613
mark-up: .91 (%)
Sell: 674
(Adult Net x child or infant %) / mark-up = Sell of child or infant
(613$ x 67%) / .91 = 451$
If on Sell (S):
example :
Net: 613
mark-up: 61
Sell: 674
(adult Net + mark-up) x child or infant % = Sell of child or infant
(613$ + 61$) x 67% = 451$
Surcharges are included in net fare.
Surcharges won’t apply if child or infant selling price is zero.
Land :
Indicates that must be sold with a land portion if check marked.
O/W:
Indicates that line is applicable to one-way fare if check marked.
1.3 Zones
The Zones option is used to define a group of city’s or countries in order to facilitate the data input.
The system makes sure that the Zone doesn’t already exists.
If you add a gateway or destination in a zone (using the Search zone), it will automatically be
added in the top information of all your negotiated fares that are attached to the zone.
Fields Description:
Code:
The Gateway zone must start with G and have a minimum of 4 digits.
The Destination zone must start with D and have a minimum of 4 digits.
City codes:
City codes must be separated by semi-colons and there must be more than one city code in order
to create a zone.
If you want to create more than one zone with the same airport codes, you can put ‘fake’ airport
codes in order to do so.
For example you could have
Zone1: YUL;YYZ;YMQ
Zone2: YUL;YYZ;YMQ;AAA
Zone3: YUL;YYZ;YMQ;BBB
2 Search
To Search and update information related to negotiated fares, Commission grids (for
private fares (ATPCO) and overrides on published fares and zones.
All Search Menus have the same functionalities. The more information is entered, the more precise
and quick your search becomes. You can then select the required line from the list provided (see
Input Menu for detailed descriptions) in order to consult, update or add information.
In both Search Negotiated and Commission grids, if fares are related to a zone that contains more
than 10 airport codes, we display the zone name with a link to see its content. If the zone contains
less than 10 airport codes, we display the list of airport codes.
2.1 Negotiated
Step 1: Find specific negotiated fares in order to view or update information.
You can fill out any field, the more information you put in the more precise the search results will
be.
You can search using either the CITY or AIRPORT codes. System will know to look for both using
relationship (REF city) in the airport table.
Choose fare grids with:
- Any seasonality (will select all matching fare grids)
- With valid dates (will select fare grids that contains some valid dates meaning that it contains
departures from today and onwards)
- Only expired dates (will select fare grids that contains ALL past departures, therefore are all
expired)
Step 2: Using provided selection criterias, list of matching fares will be displayed.
Go: To select the fare grid you wish to view or update. See section 1.1 for fields description.
The contract will automatically appear with the exact number of lines it contains + 3 free lines.
To add more than 3 new lines to contract you must specify the number of lines required in the
#line: field (default is 3)
Ins.OW: To insert the OW fare lines. It will automatically create one way fare lines using return
fare lines. You simply provide:
- the % to use on the net to create the OW fare lines inside the same fare grid;
- the fare basis you want for the one ways (you can use a dot (.) as a wild card)
- the child and infant percentages applicable on the one way fares
The system will use the existing return lines, create ow fare lines, for each of them re-calculate the
fare using the percentage provided and erase the min/max and mandatory nights values, replace
the fare basis, child and infant percentages.
Just check mark the ins. ow and click on Go.
Del: To delete a group of fares you must check mark the delete box and click on Go of the same
line.
Delete groups: You can check mark the del button on multiple group of fares and then click on
the delete groups button to delete all of them all at once.
If you want to delete the whole contract, it is better to use the delete contract utility in the Utilities
Menu because it will also delete the contract table and all specification tables linked to contract
(level 3) or group of cities (level 2).
Copy: To copy fares from specific cities (gateway/destination) to other specific cities
(gateway/destination) related to the same contract. You must check mark the copy box and then
click on go of the appropriate line. A Screen will pop up for you to specify the new cities
(gateway/destination) OR zones on which all the fares and their related specification tables will be
copied. You can also add amount ( + or - ) to the nets if required.
You can then use the Mass change utilities to make necessary changes on price or any other
information.
Avail: To make the fares available (Y) or not (N) through the booking engine.
In order to change the avail. Flag, you have to replace the value and click on Go of the same line.
To set fares available for the whole contract, you can use the Export contract utility.
2.2 Commission Grid
Find specific commission grids in order to view or update information.
You can fill out any field, the more information you put in the more precise the search results will
be.
You can search using either the CITY or AIRPORT codes. System will know to look for both using
relationship (REF city) in the airport table.
Choose fare grids with:
- Any seasonality (will select all matching fare grids)
- With valid dates (will select fare grids that contains some valid dates meaning that it contains
departures from today and onwards)
- Only expired dates (will select fare grids that contains ALL past departures, therefore are all
expired)
Using provided information, list of matching commission grids will be displayed.
Go: To select the commission grid you wish to view or update. See section 1.2 for fields
description.
The commission grid will automatically appear with the exact number of lines it contains + 3 free
lines. To add more than 3 new lines you must specify the number of lines required in the #line:
field (default is 3)
Del: To delete a commission grid you must check mark the delete box and click on ‘Go’ of the same
line.
Delete groups: You can check mark the del button on multiple group of commission grids and then
click on the delete groups button to delete all of them all at once.
If you want to delete the whole contract, it is better to use the delete contract utility in the Utilities
Menu because it will also delete the contract table and all specification tables linked to contract
(level 3) or group of cities (level 2).
Copy: To copy a commission grid from specific cities (gateway/destination) to other specific cities
(gateway/destination) related to the same contract. You must check mark the copy box and then
click on go of the appropriate line. A Screen will pop up for you to specify the new cities
(gateway/destination) OR Zones on which the commission grids and their related specification tables
will be copied.
Rename: Utility to change the commission grids contract it is linked to.
You must check mark the rename box and click on go of the specific line. Then, you must choose
the new contract name on which you want the commission grid to be linked.
Avail: To make the fares from commissions grids available (Y) or not (N) through the booking
engine. In order to change the avail. Flag, you have to replace the value and click on Go of the
same line. To set fares available for the whole contract, you can use the Export contract utility.
2.3 Zones
Find specific zones.
You can select a specific zone OR type in a city code OR click on the plane for all zones.
If you add a gateway or destination in a zone, it will automatically be added in the top information
of all your negotiated fares that are attached to the zone.
Go: To select the Zone you wish to view or update. See section 1.3 for fields description.
Del: To delete a Zone you must check mark the delete box and click on GO of same line.
If there are some fares linked to the zone, the system will not allow you to delete it.
3 General Info Menu
To maintain general information tables used by the booking engine.
3.1 Agency
The Agency option allows you to create the agencies profile and logins (per agency or per agent)
that will be allowed to access the B2B Booking Engine. Login to B2B will be validated using the
agent table or agency table (if no agents).
This table can be automatically populated using the register form provided by Openfares or your
own. Contact Openfares for more information.
The initial load can also be done using a CSV file and the import agency utility (see section 5.3)
IMPORTANT: it is important to fill out the User, Password and at least the Address 1 in 'more
info'.
If address 1 is missing, you will not be able to book using the booking engine.
You can enter specific search information and/or click on the plane to get the agency list.
The newly registered only are the agencies that have been created using the registry form,
therefore, status = N
Following search criterias are for NFO only:
By server
By Admin user
By LL user
Leisure link status
Fields description:
User :
User name of agency. If you create an agency with USER = superuser, it will allow you to see the
non available (avail = N) fares in the B2B before you export the fares.
Password :
Password of agency.
Agency name :
Agency name.
Int./ext. :
Identifies if this login is for an agency (external user) of internal user.
The internal user will be able to see all the PNR’s.
The external user will be able to see only the PNR that where booking using is agent name.
EXTERNAL :
When agency is check marked external, system will display the user name of the agency (which is
the phone number) that can not be modified.
INTERNAL:
When agency is checked marked internal, system will display the User Name of the agency. It can
be modified by the agency for which the internal agent is making the reservation for.
The field will be titled:
Agency 'STAR' (if you are using stars for agency profile) or
Agency 'User ID' (if you are using Webfares for agency profile).
If you are using Stars, make sure it is created in the GDS.
If you are using Webfares, make sure at least Address 1 field contains information in 'more info' of
Agency or else booking will not process.
Discount :
Amount to discount on agency’s selling price. Take priority over amount in Consortium.
% or $ :
Identifies if discount amount is a dollar $ amount that will be deducted from selling price or
percentage % off the mark-up.
Consortium :
Identifies consortium of the agency.
MORE INFO
Contact name :
Contact name at the travel agency.
Address/City/Country/Prov./State
Postal/Zip code
Agency GDS:
GDS of the travel agency.
GDS sign in:
GDS sign in, For e-agent Galileo customers only.
Tel. Number
Fax. Number
Email :
E-mail address where the booking confirmation will be sent.
Web site(full link):
Agency’s Web site. Not used.
Agency logo link:
To identify link of ageny logo on desk top and insert it into agency invoice destined to client. Not
available yet.
IATA/ARC
CLIA
Where did you here about our site
Preferred internal agent :
If the agency always deals with a preferred internal agent, this would contain is name.
Preferred queue:
Agency’s preferred Queue. (For Galileo only)
A copy of the PNR will be sent into the agency's queue.
Preferred Queue will be inserted in the PNR at time of booking.
Status :
Status must be blank to enable use of login on B2B Booking engine.
Any other value will desable its use.
When agency information is automatically created in webfares using the Openfares registry form on
your B2B Website (sold separatly), status will be equal to N (for New).
The agency will not be able to use it until you approuve it.
Buttons to Approve or Disapprove the new agency will be displayed when status equals to N.
- If agency is approuved, status will automatically be set to blank, therefore, agency can now login.
- If agency is desapproved, status will automatically be set to X, therefore, agency still can't login.
See appendix 5 for more information on registry form automatic e-mail process
NFO:
NFO min: For NFO internal use.
NFO amount: For NFO internal use.
Server ID: Server identification number, for NFO only.
Black List: To identify list of venders for wich this agency is on a black list, therefore not shown
farefs of those specific venders.
Galileo Netfares: Galileo Netfares, login and administrative account information, for NFO only.
Leisure link info: Leisure link login information, for NFO only.
PCC INFO
The agency PCC will be considered only if the - DEFAULT- pin code is selected in the main PCC info.
Agency PCC info is used ONLY at booking time.
Get 'Pure' Published & book in:
GDS that must be used to Get 'pure published' fares and book them.
Check avail and book in:
GDS that must be used to book (for everything but 'pure' published) for Negotiated, Private fares
(ATPCO), published with comm. overrides.
Get comm. grids & private (ATPCO) in:
GDS that must be used to get Published fares with commission overrides and Private fares (ATPCO).
FOR EACH GDS (SABRE, GALILEO, WORLDSPAN and AMADEUS)
PCC:
Pseudo city code.
Queues:
Queues and pic information for PNR queuing
PNR: where the PNR will be queued at time of booking
Pmt, pmt2: where PNR will be queued at time of payment
Reminder: where PNR will be queued once option date is reached ( sabre /Gal ) and when PNR is
cancelled.
PCC: must be filled out if vendor star is entered. PCC to retrieve the vendor star.
Format is queue/pic. If no pic entered, default value /7 will be used.
Vendor Star:
Star of vendor. The star details will be inserted in the PNR.
Private label pincodes: For NFO only.
AGENTS
To define logins per agents inside an agency.
Values in agent name, email and pref. queue will be used to automatically populated information in
the 'enter names' page.
If status is anything but blank, login will be disabled therefore no access to the booking engine.
3.2 Consolidator’s Information
The Consolidator’s information option allows you to create your vendor’s information and settings.
Fields description:
Vendor’s name and address :
Vendor’s name and address information.
*Active on ...
For NFO only, to set active on NFO and GNF platform.
*Offer published on ...:
For NFO only, to offer pure published on NFO and GNF platform.
Consolidator e-mail :
Consolidator’s main e-mail address. Used by the registry form automated process.
PNR e-mail :
Consolidator e-mail than will be inserted in the PNR (from B2B) under PE.
This e-mail will also be inserted in the E-mail sent to agency when newly registered.
Every time a booking is completed, a copy of the PNR will be sent to this e-mail.
Every time a payment attempt will be done on a PNR, a message will be sent to this e-mail.
Every time a remark is inserted in a PNR, a message will be sent to this e-mail
Send PNR e-mail to agency:
If check marked, agency will receive a copy of the PNR by email at booking and at payment time.
Show invoice :
When check marked, B2B booking engine will offer the Make Invoice option.
If so, the agency will be able to print or e-mail an invoice to their clients with the passengers
details, itinerary, total price and notes.
*Country code :
ISO 2 letters country code of Consolidator.
Default Currency :
System’s default currency.
*Logo :
File name of Consolidator’s Logo. Only for NFO.
Agency Airline :
Should contain airlines where it is allowed to give the ‘live’ file to agencies. (for nets only).
Example: LH;AC;BA
Default option days :
Will be used to calculate option date if no ADVP is found for fares. It will override the ADVP if more
restrictive in order to never give options for more than X days.
It is a number of days after reservation for Neg (negotiated) or Pub (pure published fares and
commission grids)
for more info, see Appendix 4: Advance purchase, Ticket deadline, Option date and Time limit
Minus days :
No longer used.
Cut-off time :
To determine cut off time per day of the week and days of operations.
Will be used to re-calculate option date on negotiated fares.
If current time of booking is after cut-off , system will back the date an additional day.
If option date is day date, after cut-off time, system will give a message to call in order to finalize
reservation at time of payment.
If 'closed' is selected, no options will be given for that specific day of the week.
for more info, see Appendix 4: Advance purchase, Ticket deadline, Option date and Time limit
Check (Y/N) :
Indicates if the check payment is accepted.
Fax copy Check accept (Y/N) :
Indicates if a faxed copy of check is required.
Fax number :
Where to fax the check copy.
Commission paid with ticket :
If commission check will be issued with ticket.
*Contact :
Contact name.
Credit card signed form(Y/N) :
If yes (Y), the following sentence will appear in payment page of B2B
Booking Engine.
The fax number comes from the vendor’s name and address information
Airlines are merchant:
If check marked, it means that ALL airlines are CC merchants for the consolidator.
When airline is merchant, the CC authorization is taken in the GDS and credit card fees are not
applicable.
If not check marked, it means that the consolidator is the CC merchant. Some exceptions can be
determined for specific airlines and/or contracts in Airlines fees or Contract tables.
When Consolidator is merchant, the CC authorization is not taken in the GDS and credit card fees if
present are applicable.
Credit card fees ($ or %) :
Amount or percentage of credit card fees applicable on credit card amount.
Automatically calculated on payment page. ($800 x 3% = 24.00)
Applies only if Airline is not merchant. When 2 Airlines implicated in routing, first one determines
the Airline code.
Service fee :
General service fee that will be applied per passenger (adult & child) OR per file.
Automatically calculated on the payment page of B2B
You can specify if service fee is applicable on (P) Pure published, (C) commission grid overrdies or
(N) Negotiated and private fares (ATPCO).
Applicable only if no service fees are entered in the Airline table (see section 3.9)
You can also specify if service fee is applicable per passenger (per pax) or per file.
If service fees are entered at Airline level (In Airlines table), they have priority over the ones
entered here but the option to determine if it is per pax or per file is always determined at
Consolidator info level.
GST/TVA (TPS):
Goods and service tax percentage applicable on fares and other service charges.
PST (TVQ):
Provincial sales tax percentage applicable on fares and other service charges.
Ignore mileage:
If check marked, we will ignore the mileage required from the GDS for Open Jaws. If you want the
system to validate the mileage, you must remove the check mark. You can then go in the contract
table, use the new OJ button and specify the ‘approved’ illegal open jaws.
neg: is for negotiated, Private fares and commission overrides.
pub: is for 'pure' published fares.
ADD mark-up % on Net:
To indicate how to calculate the Sell using a percentage mark-up (ex: .91 or .15 ) for negotiated
fares.
If not check marked, It is a commission on SELL, therefore, Net is divided by percentage :
Net / mark-up = Sell (500/.91 = 549). This ensure the consolidator to have a 9% mark-up.
If check marked, It is a mark-up on NET, therefore, percentage is added to Net:
Net + mark-up = Sell (500 + 15% = 575)
Child & infant on Sell or Net (S/N):
Identifies if Child and Infant selling prices should be calculated on the Net or on the Sell (Net +
mark-up) of adult fare. Default value = N.
Show date of birth:
Must be check marked if you want booking engine to ask for Date of birth for child and infants at
the 'enter names' page.
IATA number :
Consolidator’s IATA number.
Travel Organizations/web site :
Travel Organisation info ( for NFO ) or Consolidator’s web site.
The Web site address will be used in e-mail destined to approve or disapprove agency registry
request.
Remarks :
The first 2 remark lines will be inserted in display message for non-bookable flights. You can put
info on different offices to call the consolidator.
Remaining 3 lines are used only on NFO for consolidator information.
3.3 Consortium
The Consortium option allows you to create the consortium with related discount amount or
percentage.
Note: You can use the discount to input the agency commission. These commissions can be
displayed on the booking engine in a separate column and not be deducted from the applicable rate
in order to offer a 'retail' price. In order to do so, you must select the option 'retail commission' in
the Co-branding module.
Discount amounts can be specific for every contracts. In order to specify different discounts per
contract, you need to reach the consortium table inside the contract table.
Fields description:
Code : Consortium identification code. This code should then be entered in the related agencies in
the agency table.
Name : Name of the consortium.
Discount : Amount to discount on agency’s selling price for agencies that are linked to the specific
consortium.
% or $ : Identifies if discount amount is a dollar $ amount that will be deducted from selling price
or percentage % off the mark-up.
NOTE:
A negative amount will be added to the net.
Ex: -8.63 will add $8.63 to the net.
3.4 Credit Cards
The Credit cards table allows you to create the credit cards accepted through your booking engine
in the payment page.
Fields description:
Code: Credit card 2 letter code, must be the same as used by the GDS ( CA = Master Card )
Description: Name of credit card that will be displayed on booking engine payment page.
3.5 Delivery Methods
The delivery methods option allows you to create delivery methods and their applicable rates that
will be presented in the payment page of the Booking Engine.
It populates the scrolling list for Type of delivery in the booking engine payment page with
Description, amount, currency and days ( number of days for delivery )
You must indicate if the delivery method should appear on the B2B booking engines or select the
specific pin code (from B2B co-branding modules). B2C no longer uses this, it is now in the B2C
configuration file.
You can identify the Display priority of the delivery method on the payment page of the booking
engine.
IMPORTANT: If you create a delivery method for E-Ticket, make sure it contains one of the
following words:
E-TKT
ETKT
E-TICKET
ETICKET
ELECTRONIC
Only when one of these words is found, the amount for paper ticket entered in airline / service fees
will not be charged.
3.6 Eligibilty
You can create Eligibilty codes for various types of fares with requirments. Such as Age or Date requirment.
Or you can also create your own free flow text and requirments. Such as: Refugee fares, Umra fares, XXX passport
holders only etc. After you create the codes you have to attach the same code in your contract in "Fare Appl."
button that exists in 3 levels of specifications. Please refer to section 1.1.13 for details of the "Fare Appl." button.
Type is A (for Age), D (for Date) or T (for text)
The example "TCAN" code created in the Eligibilty table in General info will have to be entered in the contract the
fares apply to.
You choose the code you created from the dropdown menu to the left of the Fare Applicabililty screen. The Fare
Appl. button exists in Webfares in all 3 levels of specifications. Level1 (fare line level), Level2 (page level), Level3
(contract level) for Nego and Comm. Grid contracts.
Fare Applicabililty fields exist in Nego and Comm Grid 110 and 113 excel sheets as well. They are in 3 columns in
excel sheets. Column DD/DE/DF in 110 column version, column DF/DG/DH in 113 column version. If you have
multiple eligibility codes for your excel sheet, the fields must be separated with & sign.
Example: If you had:
ISIC card holders with age requirment of 18 and
BBB code for the date requirment of 15/11/08 and
TCAN code for your own text requirment of "Canadian passport holders only"
In your 110 version excel you would be entering:
Column DD Column DE Column DF
ISIC&BBBB&TCAN A&D&T 18&15/11/08&Canadian passport holders only
To be able to use this feature you have to turn it on in your Co-branding module by check marking
"Let users enter eligibility"
3.7 Holidays
The Holidays table allows you to specify the dates on which you do not want the option dates to
fall on. Holidays table cover only the public holidays and/or any other day your ticketing department
is closed and can not issue tickets. This would exclude the days you are closed every week. Already
receive this information from your Consolidator Info (section 3.2) Example : In your profile you
mentioned you are closed every Saturday and Sunday, this will be taken into consideration
therefore those dates don't need to be mentioned in your Holiday table.
Please make sure you enter Holiday dates at least 2 weeks prior to the Holiday therefore no
booking created with option dates falling into Holidays. It is recommended that you enter Holiday
dates once per year ahead of time.
3.8 Pseudo Airline
The Pseudo Airline option allows you to indicate the airline code and classes you want to display in
the Booking Engine for specific Airlines.
It will also replace the Airline code in the rules table.
You can specify per contract (in the contract table) if you wish to use the pseudo information or
not. Not yet linked to booking engine.
Airline / Replace with / Classes to replace:
For Airline AA Replace it with XX, replace class Y with Z and class X with J
(format YZ;XJ;etc...)
Show classes:
If show classes is set to N (No), classes will not be displayed in the booking engine.
text to display:
If you fill out the text to display, the booking engine will display the text instead of the airline
code.
3.9 Airlines
The Airlines option allows you to create service fees and provide miscellaneous information
for Airline codes that will be used throughout the system. The airline table can also be reached
through the search nego or search comm.grids. It will display only the specific airline information.
Fields description:
Code: Airline code. ex.: AC or ACLH
Description: Name of Airline that will be displayed on booking engine request page.
IMPORTANT: 'Pure' published fares can be offered only for those airlines or all airlines. Contact
Openfares for option set-up.
Service fees :
Selling Fare (per passenger, adult or child) x % = result (if % is 0, result = fare)
If result < rule, service fee = amount 1
If result > rule, service fee = amount 2
If rule = 0, service fee = amount 1
Example 1: (Delta)
If Fare = 499
499 x 7% = $34.93
$34.93 is < 37.50 so service fee = $35.00
If fare is 537
537 x 7% = $37.73
$37.73 is > 37.50 so service fee = $60.00
Example 2: (Air Canada)
If Fare = 500
500 x 0% = 0 (so result = $500)
$500 < 1000 so service fee = $25.00
If fare is 1500
1500 x 0% = 0 ( so result = $1500)
$1500 is > 1000 so service fee = $50.00
Example 3: (KLM)
Whatever the fare, service fee = $10.00
The service fee amount will be displayed in the payment page and added to the amount due. There
is a service fee field in General Info/Consolidator info that applies to all Airlines if nothing in Airline
In the PNR you will have :
10.H-SERV FEE PER ADU 35/ 2.45XG
Applies on :
Determines if service fees should apply on:
N: Negotiated fares and private fares (ATPCO)
C: Commission grids overrides on published fares
P: “pure” published fares picked up directly in the GDS using Trip Search (for SABRE), Best Buy (for
Galileo) and Power Shopper (for Worldspan).
Paper tkt surcharge:
You can also indicate the amount that needs to be charged per pax for paper tickets.
The paper ticket fees will apply only if the delivery method is anything else than E-ticket.
Paper ticket fees will be presented on the payment page.
Airline is merchant:
If check marked, it means that for that specific Airline, the Airline is the CC merchant therefore, CC
authorization will be taken in the GDS and CC fees entered either in consolidator info or Airlines
fees will not apply.
CC fees:
Amount or percentage of CC fees applicable for that Airline.
Applicable only if airline is not merchant.
If amount is < than 1, it is considered a percentage. ex. .03 = 3%
If amount is > than 1, it is considered an amount. ex. 3.00 or 3 = $3.00
Neutral Access :
If selected system will use Galileo XML select interface in NEUTRAL ACCESS instead of DIRECT
ACCESS in order to perform availability search. For Galileo ONLY.
Example: A15JUNYULLAX+UA
Sabre Neutral availability: In version 3.5 system is able to search NEUTRAL Sabre availability for
the airlines check marked as "Neutral" in the airlines table.
Mandatory night at dest.:
If check marked, it will indicate that the minimum stay AND mandatory night must be validated
using the arrival date (at destination) and not using the departure date. It will be validated at the
'enter names' page and the following message will be displayed if requirement is not valid:
The minimum stay at destination is invalid, please select another flight or date.
No passive PNR:
If check marked, no passive will be automatically generated for this airline.
The clone PNR option will not be offered.
Screen Scrape:
If selected, system will no longer use Galileo XML select interface to perform availability search. It
will use the Galileo terminal commands in DIRECT ACCESS and screen scrape the results. If for
some specific classes the GDS command must be done using these classes, you must list them.
SCREEN SCRAPE as priority over the NEUTRAL ACCESS option and is performed only in DIRECT
ACCESS.
For example, UA set to SCREEN SCRAPE and you have S in specific classes:
- On a Q class fare, system will perform availability search like this:
L@UA/A15JUNYULLAX (no specific class cause no match found)
- On a S class fare, system will perform availability search like this:
L@UA/A/S/15JUNYULLAX (using the specific S class cause match found)
If no availability is found, a second call without the class is performed in order to find up sells.
Class specific calls are performed ONLY in a POINT to POINT availability search and not in a BY
SEGMENT search.
Screen scrape is working for the airlines using the following systems:
AI, ARCO, AXRES, CAAC, CUPID, DELTAMATIC, GABRIEL, KRISCOM, MARS, RES3, SABRE, SHARES,
WORLDSPAN
Hub:
To indicate the HUB of the airline. When no availability is found using a POINT to POINT availability
search, system will try again with a BY SEGMENT search and use the HUB(s) as the VIA POINT(s).
You must have routings that contain the HUB fields for this option to work.
For example: Airline BA, HUB = LON
Fare from YUL to MIL, Airline BA, routing AC;LON;BA without a LON via point, system tries
L@BA/A15JUNYULMIL If this fails, then system will do L@AC/15JUNYULLON and
L@BA/15JUNLONMIL
This is useful if VIA POINT was omitted when it was required or if there are only a few destinations
where a VIA POINT is required and you do not want to slow the system by forcing the use of VIA
POINT on ALL destinations.
3.10 Airport codes
The Airport codes option allows you to create the Airport codes that you wish to use in the B2B or
B2C booking engine with their related description.
Note that on the B2C, the match for the name will be done on the first characters.
If for instance you create NYC for New York, you could name it ‘New York, All airports’ but be sure
to put the matching information in the beginning of the name.
Fields description:
Airport: Airport code
Language: Airport code language for name information
Name: Airport code name
Ref. city: City code that the airport is linked to.
Country: ISO country code of the Airport code.
State: State code of the Airport code
IATA: IATA zone of the Airport code
DEMONSTRATION:
City codes
NYC New York, All airports
Airport codes
EWR Newark (ref city NYC)
LGA La guardia (ref city NYC)
JFK John F. Kennedy (ref city blank, because fares are different)
B2B
Example 1:
If agency asks for NYC, we will look in City codes to see if value is there.
If found in City code table, we will then look in the Airport codes and pull up fares using airport
codes that have ref. City = NYC (EWR and LGA)
If not found in City code table, we will look for fares with the requested code
(Not applicable here because NYC is in City codes table).
Example 2:
If agency asks for LGA, we will look in City codes to see if value is there.
codes that have ref. City = LGA
(not applicable here because LGA is not in City code table)
If not found in City code table, we will look for fares with the required code (LGA) and the city
code that that is linked to it, if present (NYC).
Example 3:
If agency asks for JFK, we will look in City codes to see if value is there.
codes that have ref. City = JFK
(not applicable here because JFK is not in City code table)
If not found in City code table, we will look for fares with the required code (JFK) and the city code
that is linked to it (not applicable in this case).
B2C (Both tables must be filled for B2C booking engine)
Example 1:
If customer asks for New York, we will look in City codes and Airport codes names to see if there
are matching values and display the list (if more than one match) so that the customer can choose.
If found in City code table (by matching name), we will then look in the Airport codes and pull up
all the names that have ref. City = NYC (EWR and LGA)
Result would be:
1- New York, All Airports
2- Newark
3- La Guardia
If customer selects 1 – New York, All Airports, the system will use NYC and do the same process as
for the B2B (look for fares with EWR and LGA)
If customer selects 3- La Guardia, the system will use LGA and do the same process as for the B2B
(look for fares with LGA only)
Example 2:
If customer asks for La Guardia, we will look in City codes and Airport codes names to see if there
are matching values and display the list (if more than one match) so that the customer can choose.
If found in City code table (by matching name), we will then look in the Airport codes and pull up
fares using airport codes that have ref. City = LGA
(not applicable here because LGA is not in City code table)
If not found in City code table, we will look in the Airport codes (by matching name) and pull up all
the names that match.
Result would be:
3- La Guardia
Since there is only one, the system would look for fares with LGA
3.11 City codes
The City codes option allows you to create the city codes that you wish to use in the B2B or B2C
booking engine with their related description.
Note that on the B2C, the match for the name will be done on the first characters.
If for instance you create NYC for New York, you could name it ‘New York, All airports’ but be sure
to put the matching information in the beginning of the name.
3.12 Contracts
The Contracts option displays the list of your contracts and contract related options.
You can select one specific contract or leave the search option blank to retrieve all contracts.
This contract table can also be reached using the contract hyper link through the search nego or
search comm. grids. It will display only the specific contract information.
Fields description:
# : Contract identification.
Contract :Contract name.
Type:
Contract type
C = Commission grid contract
blank = Negotiated contract
Airline is merchant:
If check marked, it means that for that specific Contract, the Airline is the CC merchant therefore,
CC authorization will be taken in the GDS and CC fees entered either in consolidator info, in Airlines
fees table or in contract table will not apply.
CC fees:
Amount or percentage of CC fees applicable for that contract.
Applicable only if airline is not merchant.
If amount is < than 1, it is considered a percentage. ex. .03 = 3%
If amount is > than 1, it is considered an amount. ex. 3.00 or 3 = $3.00
No CC:
If check marked, no CC payment option will be available on the payment page for this contract.
Mandatory night at dest.:
If check marked, it will indicate that the minimum stay AND mandatory night must be validated
using the arrival date (at destination) and not using the departure date. It will be validated at the
'enter names' page and the following message will be displayed if requirement is not valid:
The minimum stay at destination is invalid, please select another flight or date.
Season/wk-end based on trans. segment:
If check marked, it indicates that for this contract, the seasonality and week-end surcharges are
selected using the dates of the segment that is overseas (transatlantic or transpacific).
For week-end surcharges, the system will not provide the week-end surcharge at the fares display.
(Because we need the selected itinerary in order to properly calculate the week-end using the date
of the 'overseas' segment).
It will calculate it once the itinerary is chosen. Like usual the system will display the following
message:
For week-ends: Please note that a $30 week-end surcharge is included in the rate
and include the week-end surcharge in the fare amount at the price display for the specific routing.
For season: Warning! Fares modification due to overseas validation
and include change the fare amount at the price display for the specific routing.
Faring only:
If this field is check marked, the B2B will display the fares but not allow availability search. When
clicking on availability search, the system will display message to contact the consolidator and print
the first 2 remark lines from consolidator info table.
Nb. move down:
To specify the number of move downs per contract that the booking engine should make in the GDS
to retrieve availability. If nothing is specified, the system will do 4 move downs for a regular search
and 2 move downs per legs for a segment by segment search.
Dom:
To identify domestic contracts. Right now, it is not used by the booking engine but it can be a
usefull way to group these contracts and select them in the mass change contract ( to make a quick
mass change on all Domestic contracts)
First effective day:
To identify a specific date from which this contract can be offered on the web.
Format is YYYY-MM-DD.
OSI(button):
You can enter specific OSI's (10 OSI per contract) that will be inserted in the PNR's.
the full OSI command must be entered.
COM(button):
This button is divided in 2 sections:
a) Commissionable fares:
You can enter information related to commissionnable fares.
The commission amount will be applied only if fare is 'with land' and is used to have a global markup in order to determine a general land portion value.
Commission amount: Commission to apply on fare. (ex 1.22, we will do fare x 1.22)
Applicable on Sur.: Determines if commission is applicable on fare+surcharge
Applicable on Wk-sur.: Determines if commission is applicable on fare+week-end surcharge
Round up/down: Determine if fare should be rounded up or down the nearest dollar.
b) Kids fly free and promotions and companion fares
You must select either the Kids fly free OR the Promotion.
If promotion is selected, you must identify the % discount related to that promotion.
Nb.pax:
To identify quantity and type of passenger applicable.
1C means 1Child
2C means 2 children
etc...
1A means 1 adult
2A means 2 adults
etc...
For both kids fly free and promotions, the rule must be clearly identified.
For example:
Kids fly free, nb.pax 1C per paying 1 adult
(means 1 free child per paying adult)
Promotion 50%, nb. pax 2C per paying 1 adult
(means 2 child at 50% per paying adult)
Companion fare 30%, nb.pax 1A per paying 2 adults
(means 1 adult with 30% discount per 2 paying adults)
Applicable on Sur.: Determines if promotion is applicable on surcharge
Applicable on Wk-sur.: Determines if promotion is applicable on week-end surcharge
Round up/down: Determine if fare should be rounded up or down the nearest dollar.
TAX(button):
You can specify the extra taxes per contract. They will have priority over the ones in the general
information per Airline.
see section 3.6 Extra taxes
OJ(button):
This table is used to identify the list of 'approved illegal openjaws'.
You must specify the gateways and destinations for which the mileage restriction can be ignored.
The 'applicable on' field is to identify if Open jaw is permitted on
D destination
O origin
B both (origin and destination)
E either (origin or destination)
TKT(button):
E-tkt not allowed:
You can identify if E-Ticket is
- Mandatory (Only E-ticket option will be offered in the payment page)
- Permitted (At payment, system will offer E-ticket option only if permitted in the GDS)
- Not permitted (E-ticket optin will not be offered in the payment page)
Note that a cross validation with the GDS is done only when the 'permitted' option is selected.
Bulk:
If check marked, it means it is a bulk contract. Means that tickets from this contract needs to be
issued using a bulk ticket stock. Used by ticketing module.
Plating carrier:
Airline code of the plating carrier, used by ticketing module.
Paper tkt surcharge:
You can also indicate the amount that needs to be charged per pax for paper tickets.
The paper ticket fees will apply only if the delivery method is anything else than E-ticket.
Paper ticket fees will be presented on the payment page.
TKT detail:
Any ticket information you want to display in TKT box at fare display of your B2B engine.
TKT detail must be selected in the co-branding module as a column to display.
Max 12 alphanumeric characters.
TKT type:
Any ticket information you want to display in TKT type box at fare display of your B2B engine.
TKT type must be selected in the co-branding module as a column to display.
Max 12 alphanumeric characters.
TKT Notes:
You can type any ticketing information that you will want Internal users to see at file display.
OTH(button):
Max % on CC:
When airline is merchant, you can specify the maximum amount that can be charged on the credit
card. The amount will be calculated on the net fare (+ taxes) using the percentage entered.
example: 20%
If net is $500, taxes are 100$ (+ 50 mark-up = sell $650), the B2B will make sure that the
amount charged on the credit card doesn't exceed 20% of the net fare + taxes ($600 + 20%) =
$720
Note: For “pure” Published and Published fares with commission overrides, the system will make
sure that the Credit card amount in the payment page does not exceed the published fare + service
fees.
Nb. free nights:
When surcharges for land protions are calculated per 'nights', this field allow you to indicate the
number of free nights allowed.
ex.: travel is for 10 nights, you charge $40 per night and have 2 free nights, the system will
calculate the surcharge for 8 nights (10 night total - 2 free nights).
Special ADVP:
Special ADVP:
For USAIR contracts, it was required to consider only the AFTER field to calculate ADVP and not to
override it with default option days.
Lets take example where today is NOV 19
And we are trying a departure DEC 04
ADVP is the Following :
Before 1 : 0
After 1: 14
Before 2: 14
After 2: 3
Before 3: 3
If Special ADVP is not check marked, you will get the following:
Default option days 7 (option date = 26 NOV)
For departure DEC 04, NOV 19 is 15 days prior to departure, so, the system will check 14 days
before dept (NOV 20) or 14 days after reservation (DEC 3)
The most restrictive is NOV 20 so option date would be NOV 20
If Special ADVP is check marked, you will get the following:
Default option days is not checked.
For departure DEC 04, NOV 19 is 15 days prior to departure, so, the system will check 14 days
after reservation (DEC 3) only.
Option date would be DEC 3
Add. comments only (rules):
If you check mark this field, only the additional comments entered in the rules table will be
displayed in the B2B.
Do not book live :
If check marked, will create PNR in BK (GK, YK in construction). Only for customers with this
option. Contact Openfares for more information.
Calc. child/infant on sur.:
If check marked, system will calculate the child and infant fare on the net + surcharges
(surcharge & week-end surcharge).
If not check marked, the system will calculate the child and infant fare on the net and then add
the surcharges (surcharge & week-end surcharge) therefore, the child and infant percentage is not
applied on the surcharge and week-end surcharge amounts.
AA (Allowed airports) :
You can identify for a specific city the ‘allowed’ airports.
The format is the following:
City, allowed airport - allowed airport - etc ; city, allowed airport - allowed airport; etc…
For example:
If you want to restrict Detroit to allow only DTW and if you want to restrict Boston to allow only
BOS and BED for availability you must enter the following information:
DTT,DTW;BOS,BOS-BED
When request is done using the city code DTT, it will check availability only for DTW.
When request is done using the city code BOS, it will check availability only for BOS and BED.
Wk-end priority:
If check marked, whole amount of week-end surcharge will apply if either days OUT or IN are
applicable.
Ex: $60 days out: 567 days in: 567
If oubound OR inbound in Friday, $60 week-end surcharge.
Use webfares rules for commission grids:
If check marked, system will no longer retrieve the rules in the GDS for commission grid fare.
It will display whatever is entered in webfares rules.
Hide fare basis:
If check marked, fare basis for this contract will not be displayed througout the booking engine.
Hide routings:
If check marked, routings will not be displayed througout the booking engine.
PF modifier :
This is only for SABRE Private Fares. It is used to indicate per contract if PF modifier that the
booking engine must use to retrieve them should be NEG or CB.
Default value is NEG.
Apply pseudo air:
To determine if information in pseudo air table should be used or not for the specific contract. Not
yet linked to booking engine.
PCC Info (button):
For GDS, PCC and queues per contract.
The contract PCC will be considered only if the - DEFAULT- pin code is selected in the main PCC
info.
FOR EACH GDS (SABRE, GALILEO, WORLDSPAN and AMADEUS)
PCC:
Pseudo city code.
Queues:
Queues and pic information for PNR queuing
Reminder: where PNR will be queued once option date is reached ( sabre /Gal ) and when PNR is
cancelled.
PCC: not used ( for multi vendors only)
Vendor Star:
Consortium (button):
This allows you to specify consortium information per contract.
Fields are the same as describded in section 3.4 consortium
Allot (button):
Fares must be created with fare type AL (for allotment)
Step 1)
Once in Charter Schedules, you must fill out the line with all the flight information, date range,
default allotment and click on Allot in order to generate the Allotments for each and every dates
(using the 'default value' for seat allotments).
Step 2)
You can correct the allotments per dates, remove some, etc and click on the PLANE at the bottom
to SAVE the information.
-- > if you change the date range in STEP 1) and system must:
a) remove some dates:
System will prompt you with dates to delete and you must confirm by saving info.
Note: if booking are already confirmed on those dates, system will not delete the allotment record.
b) must add some dates:
Syste, will prompt you with the new dates and must must confirm by saving the info.
Every time a booking is done on that allotment, the BOOKED is incremented and vice versa when
booking is cancelled.
A passive PNR will be created in the GDS according to clients needs
3.13 Extra Taxes
The Extra Taxes option allows you to enter your own amounts for security taxes (Q or YQ) or any
amounts (such FC for Fuel surcharge or XF) that are not provided by the GDS. These amounts will
be added to the tax column in the Booking Engine.
The amounts will be included in the tax breakdown in the PNR, but identified separatly in the PNR:
SURCHARGE: 30Q
If you wish to include the extra taxes amounts in the selling price instead of the tax breakdown,
you can do so with a specific option. You must contact Openfares.
IMPORTANT: if an extra tax is created in webfares, system will no longer look in the fare
construction lines to retrieve the Q surcharge EXCEPT if the tax code created is XF or FC.
Extra taxes can also be entered by 'contract', see Contract table.
Fields description:
Currency:
Currency of tax (CA or US) if other than CA or US, put NA, system will take default currency of
vender.
Airline:
Airline code.
Amount :
Amount of extra tax.
Rule:
Applicable rule for extra tax.
S = by segment, T = total trip, H = half trip
Inter./Dom.:
Identifies if extra tax applies to International (I), Domestic flights (D) or Both (B).
Net/Pub.:
Identifies if extra tax applies to
Net: Negotiated fares (nets, private fares, commission grids)
and/or
Pub: 'pure' published fares.
Code:
Code that will be used in the PNR to identify the extra tax in the tax breakdown.
Destinations:
Destinations for which the extra taxes apply.
You can enter a list of destinations separated by ;
ex.: YYC;YVR
Tax:
To identify if taxable (gst/pst) or not.
Check mark means taxable.
Sur.:
To identify if the extra tax should be part of a separate 'Surcharge' column at fare display of the
B2B booking engine. Not yet linked to the booking engine.
3.14 PCC Information
The PCC Information option allows you to maintain PCC and Queues information required by the
booking engine. This is important for availability and booking process of the booking engine.
You are now able to identify the GDS, PCC and queues
per contract (In contract table )
per agency (In agency table)
per pin codes or as DEFAULT (In PCC information table )
If you do not wish to have different GDS, PCC and Queues per pin codes, just leave the actual
information attached to –DEFAULT- in the Pin code list.
If PCC is identified per PIN CODE - it as priority over EVERYTHING for both availability AND booking
process.
If nothing per pin code but only at - DEFAULT For Availability, priority is : Contract PCC / Agency PCC / - DEFAULT- PCC
For Booking, priority is: Agency PCC / Contract PCC / - DEFAULT- PCC
Fields description:
Pincode:
The list of B2C and B2B pincode is provided. You can Identify different GDS, PCC and Queues per
pin code. If you do not wish to have different information per pin code, just assign the values to
the -DEFAULT- pin code.
The agency PCC and Contract PCC will be considered only if the - DEFAULT- pin code is selected in
the main PCC info.
PCC information per Pin Code as priority on ALL other PCC information (agency, contract and B2C
config.)
FOR EACH GDS (SABRE, GALILEO and WORLDSPAN)
PCC:
Pseudo city code.
Queues:
Queues and pic information for PNR queueing
Reminder: where PNR will be queued once option date is reached and when PNR is cancelled.
PCC: PCC in which the vendore star must be retrieved. Mandatory if you are using a vendor star.
Vendor Star:
Make sure the PCC in the QUEUES is indicated.
3.15 Settings
The Settings table allows you to identify miscellaneous settings for either Webfares or the booking
engine. Most settings that now need to be done by Openfares will eventually be included in that
new option.
Fields description:
For agency logins, key is:
Right now, the system default is user and password, so there can be many users with same
username but different passwords.
If you select user only, the import agency and registry form will make the user name unique,
therefore not allow same user names with different passwords.
Timeout idle WebFare login after:
For security purpose, you can set up a certain amount of time for an automatic time out of
webfares users.
If login is idle (no action) for more than the specific time, the user will automatically be logoff.
3.16 Promotions
You can create a new promotion and disable your existing promotions, hide disabled promotions but
you can't permanently delete your promotions.
Using the new promotion, you can create a discount for a specific city pair, between certain dates
as Round Trip or One way or Both. You can choose to display the fare to B2B or B2C or both.
Discount can be entered as dollar amount or percentage. You can also choose to display it for only
a certain Consortium or Agency.
The promotional fares will display with * sign at the fare display screen. The user will be able to see
the full promotion info in the payment (enter names) page.
4. View
To view (report) information related to negotiated fares.
4.1 View Negotiated
Find a specific fare line in the FARES TEMPLATE database in order to consult all its related
information. Once a specific fare line is selected you get a formatted report of all the information
related to that fare line.
4.2 View Taxes
To view the tax file that as been imported using the Import Tax (see section 5.4 Import taxes)
You can select a specific Gateway, destination and/or Airline.
If you leave the selection blank, you will get all the list.
5 Import Menu
To import negotiated fares and agency profile information into your Webfares database using excel
spreadsheets.
5.1 Import Excel NEGO
We have done major improvements for import in version 3.5. You don't have to use an FTP program to
load your excel files anymore. You will be a list of all your files in the Import tabs without using a
dropdown menu. You must first save your XLS file in CSV format and then save the file as CSV (comma
delimited).
You should specify the format used in your excel sheet. In the cell A3, you must write the type of sheet
(nego or cg) followed by the total number of columns used. Letters "nego" and "cg" are reserved words.
Currently Accepted Excel Formats:
Negotiated CSV: 127, 154, 110, 112, 113
Commission Grid CSV: 110, 113, 115
Examples of A3 cell content: nego113, cg110
Excel templates are provided by Openfares. Latest templates(110 and 113) contain built in documentation
for each field. You can refer to section 1.1 for fields documentation and specification tables.
Upload Excel files:
If you have a new file to load, simply click "BROWSE" button to the left of the page. You will be browsing
your pc for the file. When you find your .csv file import by using "send" button. This process replaces the
FTP upload. Then you will be able to see your file to the right of the page, in red. At that point you have
the choice of 1) Importing the file by clicking the IMPORT button or 2) Delete the loaded file by clicking
the "Recycle bin" icon to the right of the line.
Depending on the size of the file you will be seeing a data transfer menu. You may not see it for small
files as they are loaded very fast. The system will only accept .csv files.
IMPORT OF LARGE CONTRACTS IN WEBFARES 3.5 AND UP
Releases 3.5 & up of Webfares we are using a new approach to re-import already existing large
contracts. Instead of deleting the contract completely and then import the new one completely, it
renames the old one to "[name]_DEACTIVATED", deactivates this old contract and imports the new one.
That results in faster import times (the ASP platform and some of the largest stand-alone OpenFares
customers) where the difference can be very significant. Since record deletions are slow, it is timeconsuming to delete the whole contract and re-import it again, so Webfares 3.5+ just renames the old
contract instead of deleting it, and the user will delete the old contract later, ideally out of the peak
periods.
The old contract cannot cause problems to the new one because the old one is automatically set to
'Avail=N'. Note that it is nonetheless recommended to go delete the old "_DEACTIVATE" contracts once in
a while, out of the peak periods. It is recommended only for reasons of performance, because deleting
these contracts will make smaller databases, and smaller databases will result in better performance at
the database level.
As a consequence of this new feature: after you re-import a CSV sheet into Webfares, the fares
associated to that sheet are not active by default, because it's like importing a new contract. You must go
under "Export" > "Contract=Y" and select your contract from the list in order to make it active, just like
you would do when you import a completely new contract. Until you do that, neither your old contract nor
new contract is active, so neither one will be showing in the booking engine.
There is no way to deactivate this new feature at the moment, but the satisfaction rate is very high.
Some of the heaviest OpenFares users have been live with that feature for months before the final
release of Webfares 3.5, and they really appreciate it because it can save them a lot of time when they
re-import an old contract, especially during peak periods when the database is more heavily used.
The threshold of "large" contracts is currently set to 500 lines in Webfares 3.5, 3.6 and 3.6.1 .
Download Excel files:
To download a file, click on the file name. You will be prompted with a user/password dialog box. You
need to enter the .csv folder user/password (your FTP directory user/password) to download the file. For
the user/password please refer to the "Links/Passwords" list provided you during the training or account
set up. If you don't have this information please open a Melvin to Openfares. Please note you will be able
to download only the Excel files you loaded. You can't download a file created in Webfares.
When you re-import an excel file, the system keeps the same page and contract specifications of each
contract. So, If you have entered specifications using Webfares at contract level or page level, they will
be kept as they were. ANY specification entered in Webfares fare line level will be overwritten when the
Excel file is re-imported. Please note,the fare line is the most restricted level of specifications. Therefore
Excel always inserts all fare specifications per fare (fare line level). Search:
The "Negotiated" and "Commission Grids"links on the top left corner of the page displays a list of files for
each type.
You can also search for files with full or partial file names. Such as a search for "CAK" in the import nego
menu will return only a list of files that has letters "CAK" in the file name.
If the "export Webfares contracts into excel" feature enabled you can view and manage all exported files
on the left side of the Import menu. If so you will be able to search for 4 different items.
Exported items:
Negotiated
Commission grid
Imported items:
Negotiated
Commission grid
Download excel templates:
You can download the latest versions of Nego and Commgrid excel sheets by using the "Templates" link
on the left of the page.
Important for Excel spreadsheets:
- The list separator must be a coma ‘,’
- The value separators must be ‘;’
- The dates format must be: DD/MM/AAAA or DD-MM-AAAA or DD/MM/AA or DD-MM-AA
- Make sure mandatory fields are present.
- Make sure rules do not contain semi-colon characters.
- The gateway (and destination) can either be one or more airport code or zone
identification.
Examples (Zones G001 and D001 must first be created in WEBFARES)
Gateway --> Destination
YUL --------> YYZ
YUL;YYZ --> YYC;YVR
YUL --------> D001
YUL;YYZ --> D001
G001 ------> YYC ;YVR
G001 ------> YYC
G001 ------> D001
Whenever there is more than one gateway or destination code, the system looks if a zone exits. If not,
the system will automatically create using the following format: DESTserialnumber, GATserialnumber
New Excel sheet(113 column):
Three new columns added to the latest 110 column excel sheet. New 113 column is now available for
NEGO and COMMGRID. You must have received an e-mail with the new excel sheets. In 3.5 IMPORT
screen all the available Excel sheets are available to download.
Please note: You don't have to convert all existing sheets to the latest 113 format. We still support 127,
154 and 110 column versions. But it is suggested that you start using 110 or 113 when creating a new
contract. New feature in this version in cell A3 of each sheet please type the excel sheet type and
version. Such as : "commgrid113" or "nego113" Entry is case sensitive. No spaces.
-EXCEL NEGO(113):
3 new fields added to the 110 version:
*Column X -Sell Fare (Field not read by Openfares, text field for the fare loader)
*Column CH -Second change rule field
*Column DI -Memo text field (Fare loader's notes, not read by Openfares. You can use all characters in
this field.)
Excel sheet notes:
Your excel templates will be provided in .xls format as usual. You have to convert to .csv (comma
delimited) format before loading. No , or ; characters are allowed column CG and beyond. No space in
the file names.
5.2 Import Excel Comm Grid
We have done major improvements for import in 3.5. You don't have to use an FTP program to load your
excel files anymore. You will be a list of all your files in the Import tabs without using a dropdown menu.
You must first save your XLS file in CSV format and then save the file as CSV (comma delimited).
Excel format is provided by Openfares. It contains built in documentation for each fields. You can refer to
section 1.2 for fields documentation and section 1.1 for specification tables as they are the same as for
NEGO.
You can now specify the format used in your excel sheet. In the cell A3, you must write the type of
sheet (nego or cg) followed by the total number of columns used. Letters "nego" and "cg" are reserved
words.
Currently Accepted Excel Formats:
Negotiated CSV: 127, 154, 110, 112, 113
Commission Grid CSV: 110, 113, 115
Examples of A3 cell content: nego113, cg110
Excel templates are provided by Openfares. Latest templates(110 and 113) contain built in documentation
for each field. You can refer to section 1.1 for fields documentation and specification tables.
Upload Excel files:
If you have a new file to load, simply click "BROWSE" button to the left of the page. You will be browsing
your pc for the file. When you find your .csv file import by using "send" button. This process replaces the
FTP upload. Then you will be able to see your file to the right of the page, in red. At that point you have
the choice of 1) Importing the file by clicking the IMPORT button or 2) Delete the loaded file by clicking
the "Recycle bin" icon to the right of the line.
Depending on the size of the file you will be seeing a data transfer menu. You may not see it for small
files as they are loaded very fast. The system will only accept .csv files.
IMPORT OF LARGE CONTRACTS IN WEBFARES 3.5 AND UP
Releases 3.5 & up of Webfares we are using a new approach to re-import already existing large
contracts. Instead of deleting the contract completely and then import the new one completely, it
renames the old one to "[name]_DEACTIVATED", deactivates this old contract and imports the new one.
That results in faster import times (the ASP platform and some of the largest stand-alone OpenFares
customers) where the difference can be very significant. Since record deletions are slow, it is timeconsuming to delete the whole contract and re-import it again, so Webfares 3.5+ just renames the old
contract instead of deleting it, and the user will delete the old contract later, ideally out of the peak
periods.
The old contract cannot cause problems to the new one because the old one is automatically set to
'Avail=N'. Note that it is nonetheless recommended to go delete the old "_DEACTIVATE" contracts once in
a while, out of the peak periods. It is recommended only for reasons of performance, because deleting
these contracts will make smaller databases, and smaller databases will result in better performance at
the database level.
As a consequence of this new feature: after you re-import a CSV sheet into Webfares, the fares
associated to that sheet are not active by default, because it's like importing a new contract. You must go
under "Export" > "Contract=Y" and select your contract from the list in order to make it active, just like
you would do when you import a completely new contract. Until you do that, neither your old contract nor
new contract is active, so neither one will be showing in the booking engine.
There is no way to deactivate this new feature at the moment, but the satisfaction rate is very high.
Some of the heaviest OpenFares users have been live with that feature for months before the final
release of Webfares 3.5, and they really appreciate it because it can save them a lot of time when they
re-import an old contract, especially during peak periods when the database is more heavily used.
The threshold of "large" contracts is currently set to 500 lines in Webfares 3.5, 3.6 and 3.6.1 .
Download Excel files:
To download a file, click on the file name. You will be prompted with a user/password dialog box. You
need to enter the .csv folder user/password (your FTP directory user/password) to download the file. For
the user/password please refer to the "Links/Passwords" list provided you during the training or account
set up. If you don't have this information please open a Melvin to Openfares. Please note you will be able
to download only the Excel files you loaded. You can't download a file created in Webfares.
When you re-import an excel file, the system keeps the same page and contract specifications of each
contract. So, If you have entered specifications using Webfares at contract level or page level, they will
be kept as they were. ANY specification entered in Webfares fare line level will be overwritten when the
Excel file is re-imported. Please note,the fare line is the most restricted level of specifications. Therefore
Excel always inserts all fare specifications per fare (fare line level). Search:
The "Negotiated" and "Commission Grids"links on the top left corner of the page displays a list of files for
each type.
You can also search for files with full or partial file names. Such as a search for "CAK" in the import nego
menu will return only a list of files that has letters "CAK" in the file name.
If the "export Webfares contracts into excel" feature enabled you can view and manage all exported files
on the left side of the Import menu. If so you will be able to search for 4 different items.
Exported items:
Negotiated
Commission grid
Imported items:
Negotiated
Commission grid
Download excel templates:
You can download the latest versions of Nego and Commgrid excel sheets by using the "Templates" link
on the left of the page.
Important for Excel spreadsheets:
- The list separator must be a coma ‘,’
- The value separators must be ‘;’
- The dates format must be: JJ/MM/AAAA or JJ-MM-AAAA or JJ/MM/AA or JJ-MM-AA
- Make sure mandatory fields are present.
- Make sure rules do not contain semi-colon characters.
- The gateway (and destination) can either be one or more airport code or zone
identification.
Examples (Zones G001 and D001 must first be created in WEBFARES)
Gateway --> Destination
YUL --------> YYZ
YUL;YYZ --> YYC;YVR
YUL --------> D001
YUL;YYZ --> D001
G001 ------> YYC ;YVR
G001 ------> YYC
G001 ------> D001
Whenever there is more than one gateway or destination code, the system looks if a zone exits. If not,
the system will automatically create using the following format: DESTserialnumber, GATserialnumber
New Excel sheet(113 column):
Three new columns added to the latest 110 column excel sheet. New 113 column is now available for
NEGO and COMMGRID. You must have received an e-mail with the new excel sheets. In 3.5 IMPORT
screen all the available Excel sheets are available to download.
Please note: You don't have to convert all existing sheets to the latest 113 format. We still support 127,
154 and 110 column versions. But it is suggested that you start using 110 or 113 when creating a new
contract. New feature in this version in cell A3 of each sheet please type the excel sheet type and
version. Such as : "commgrid113" or "nego113" Entry is case sensitive. No spaces
-EXCEL COMMGRID(113):
3 new fields added to the 110 version:
*Column AD -Not in use yet
*Column CH -Second change rule field
*Column DI -Memo text field (Fare loader's notes, not read by Openfares. You can use all characters in
this field.)
Excel sheet notes:
Your excel templates will be provided in .xls format as usual. You have to convert to .csv (comma
delimited) format before loading. No , or ; characters are allowed column CG and beyond. No space in
the file names.
5.3 Import Agencies
This utility allows you to import a csv file containing agencies into Webfares.
If agency already exists, information will be overwritten. If agency doesn’t already exist, it will be
created. See section 3.1 for field description in the csv file.
You can export the agencies file which would send an e-mail you and use the attachment received
as the template.
The file must be transferred on the Linux in the same directory as the excel spreadsheet
(home/excel-std/vendor code).
Username and password are mandatory fields. If you are not using stars for agency information,
make sure Address 1 field and e-mail field is there or else booking will not be possible.
5.4 Import Taxes
This is an additional module that must first be purchased and then set to <ON> by Openfares.
This utility allows you to import into Webfares, a csv file containing taxes(estimated) for specific
gateway, destinations and airlines (or using wild cards).
The file must first be created and imported into webfares.
The booking engine then uses these values in order to display a tax amount in the first screen of
fares display (in the estimated tax column). At the 'enter name screen', you can either (this is an
option) show the estimated taxes (which is a very efficient way to reduce GDS scans) or show the
real GDS taxes (no scan save).
At booking time, GDS taxes are inserted in the PNR. GDS taxes are also used to update the tax
info previously loaded in order to keep the must accurate amount. When a wild card was used, a
new entry is created in the database.
So for instance, you have uploaded YYY to YYY with AC $100, system will show estimated tax of
$100 at fares display for any gateway or destination of AC.
At time of booking, system will display and charge the REAL tax amount, for example YUL PAR with
AC tax = $115.64. The system will automatically create a new TAX entry for YUL to PAR with AC of
$115.64.
So, next time a request is done for YUL to PAR with AC, system will show the estimated taxes of
$115.64 (instead of $100) and therefore, automatically become more and more accurate.
The format of the .csv file is the following:
A. Gateway (YYY means any gateway)
B. Destination (YYY means any destination)
C. Airline (YY means any airline)
D. Tax amount for one way fares
E. Tax amount for return fares
F. Add GST (Y or N)
G. Add PST (Y or N)
The file name MUST be ext_tx.csv
You simply FTP your file in the same directory as your excel file, click on Import Taxes.
You will get:
IMPORTING TAXES ...
IMPORTING TAXES ...
IMPORTING TAXES ...
IMPORTING TAXES ...
IMPORTING TAXES ...
IMPORTING TAXES ...
IMPORTING TAXES ...
IMPORTING TAXES ...
IMPORTING TAXES ...
IMPORTING TAXES ...
DONE
You can then use the View Taxes utility to view your data (section 4.2)
6 Export Menu
To make fares 'available' or 'not available' on the Web booking engine, to export fares to NFO and
to export agency profile information into an excel format.
When fares are imported in WEBFARES or Mass Changed, 'available' flag is set to NO so they are
not yet displayed through the Web Booking engine.
The Export function will set the available 'flag' back to YES.
6.1 Contract=Y
The Contract=Y utility is used to set available flag to ‘Y’ on all the fares linked to a specific
contract. When fares are avail = Y, they are offered on the Web booking engine.
New module to download Webfares files into Excel:
This feature to be enabled by Openfares. When activated, the file name will show as a link in the
Export menu. You will be able to right click on the file name and "save target the file as".
If the feature enabled you can view and manage all exported files on the left side of the Import
menu. If so you will be able to search for 4 different items.
Exported items:
Negotiated
Commission grid
Imported items:
Negotiated
Commission grid
6.2 Contract=N
The Contract=N utility is used to set available flag to ‘N’ on all the fares linked to a specific
contract. Fares will not be presented on the Web (unless you use the superuser login!, see agency,
section 3.1)
6.3 All=Y
The All=Y utility is used to set available flag to ‘Y’ for all the fares of the FARES TEMPLATE
database. This should be used cautiously as it will go through all your contracts and activate them
all. If you want to use this utility please choose off peak hours.
6.4 Export NFO-Nego
The Export NFO-Nego utility was used to export your contracts of negotiated fares to NFO.
It is done automatically now, therefore this tab is not in use.
6.5 Export Agencies
The Export Agencies utility is used to export all agencies information in a .csv format file. the
format is the same as the one used for the import agencies (see section 5.3).
The file will be called agencies.vendorcode
It will reside in the same directory as the excel files.
7 Utilities
Utilities to facilitate data input and maintenance.
7.1 Mass Change Nego
To mass change information in Negotiated fare lines or specification tables related to negotiated
fares.
The new information generated using a mass change on specification tables such as Routings,
Restricted flights, ADVP, etc…is always generated on the Fare line level 1 (specs ‘S’). Therefore, it
will have priority on any info registered on Global level 2 (spec ‘G’) or Contract level 3 (spec ‘C’).
Once the Mass Changes are successfully done, you have to Export these updated contracts (set
available flag to ‘Y’) because the mass change automatically sets the flag = 'N'
7.1.1 Negotiated
This utility allows you to do a mass change on any of the fields related to negotiated fares. The
changes are done in FARES TEMPLATE database for all fares lines matching the selection criteria’s.
You first have to fill the required selection criteria on top of page.
Then, in any of the displayed fields, you simply have enter the information you wish to replace for
all fares that will match the selection criteria.
- If you put an ‘x’ in a field, it will remove the information it contains. Available for all fields except
OW.
- In Net and Mark-up, you can put the amount or the difference (+ or -) you want to apply to the
amount. Example: If you have a mark up of $50 and want to change it to $40 you can enter either
40 or –10.
If your original mark up is a positive number such as 50 by entering a negative number such as -10
in the mark up field you make the system calculate the difference and display 40.
If both the original mark up and new mark up are positive or negative we will replace the first
value.
Currently if the original amount is a large - number and you want to get the difference by entering
a positive number, it will replace the value. Where as it should have replaced the original mark up.
This is requested as a development.
- In the Land field, you can enter Y (yes), N (no) or X to remove existing value.
(blank value is equal to N)
- To set infant or child % to zero, you must enter 0.00
- Currency and Airline are fields related to group of fares. Make sure your selection criteria’s are
either contract and/or (gateway & destination). Any selection criteria’s related to specific fare lines
will not be taken under consideration.
7.1.2 Routing
This utility allows you to do a mass changes on routings. Changes are done in FARES TEMPLATE
database for all fares lines matching the selection criteria’s.
You first have to fill the required selection criteria on top of page. At lest one selection cristeria
must be selected.
Important :
- If you check mark the Add box, it will add the routings to existing information.
- If you do not check mark the Add box, it will erase all existing routings for matching selection and
replace it with this new information.
- If you check mark the Delete box on the top part, it will delete all the routings related to the
selection criteria’s.
- If you check mark the Delete box at the end of the routing, it will delete all the routings with the
same routing and via information.
This utility allows you to do a mass change on restricted flights. You can either add or delete
restricted flights. The changes are done in FARES TEMPLATE database for all fares lines matching
the selection criteria’s.
You first have to fill the required selection criteria on top of page. At least 1 selection criteria must
be selected.
To add restricted flights, airline and flight numbers must not match any existing entries (of selected
information) and delete box not checked.
To delete restricted flights, airline and flight numbers must match existing entries (of selected
information) and delete box checked.
7.1.4 Open Jaw
This utility allows you to do a mass changes on Openjaws. Changes are done in FARES TEMPLATE
be selected.
Important :
- If you check mark the Add box, it will add the openjaw to existing information.
- If you do not check mark the Add box, it will erase all existing openjaws for matching selection
and replace it with this new information.
- To delete open jaw information zone, type, with zone and with type must match existing
information and delete box checked.
- Zone and Type must all be the same on each line.
7.1.5 Seasonnality
This utility allows you to do a mass changes on Seasonnalities (dates from and to of fares).
Changes are done in FARES TEMPLATE database for all fares lines matching the selection criteria’s.
To remove a complete season from a contract: Use the same season (from and to) in the 'use' &
'and create' fields and do not keep the fare line.
You first have to fill the required selection criteria on top of page.
Then, you have to specify the seasonnality dates you wish to use to Create other fares lines with
different seasonnalities. If you wish to keep the original fare lines, you must check mark the "keep
fare line'.
7.1.6 Week-end
This utility allows you to do a mass changes on week-end surcharges. You can change, add or
delete week-end surcharges. Changes are done in FARES TEMPLATE database for all fares lines
matching the selection criteria’s.
be selected.
To change information (amount and days) on existing week-end surcharges, valid dates must match
with existing entries.
To add week-end surcharges, valid dates must not match any existing entries (of selected
To delete week-end surcharges, valid dates must match existing entries (of selected information)
and delete box checked.
7.1.7 Black-Out
This utility allows you to do a mass changes on black out dates. You can add or delete black-out
dates. Changes are done in FARES TEMPLATE database for all fares lines matching the selection
criteria’s.
be selected.
To add black-out dates, valid dates and Out/in indicator must not match any existing entries (of
selected information) and delete box not checked.
To delete black-out dates, valid dates and Out-in indicator must match existing entries (of selected
7.1.8 Surcharge
This utility allows you to do a mass changes on surcharges. You can change, add or delete
surcharges. Changes are done in FARES TEMPLATE database for all fares lines matching the
be selected.
To change information (amounts) on existing surcharges, valid dates must match with existing
entries.
To add surcharges, valid dates must not match any existing entries (of selected information) and
delete box not checked.
To delete surcharges, valid dates must match existing entries (of selected information) and delete
box checked.
7.1.9 Rules
This utility allows you to do a mass changes on Rules. Changes are done in FARES TEMPLATE
You first have to fill the required selection criteria on top of page. If you leave everything blank, it
will apply to all contracts.
- If you put an ‘x’ in field (first character) , it will remove the information it contains.
- If you put an ‘X’ in all fields (first character), it will delete the whole table.
- If you leave a field blank, it will leave existing information. Therefore, if you put information in a
field, it will replace only the fields with new information.
7.2 Mass Change C.G.
To mass change information in Commission grid lines or specification tables related to Commission
grids.
The new information generated using a mass change on specification tables such as Routings,
Restricted flights, ADVP, etc…is always generated on the Fare line level 1 (specs ‘D’). Therefore, it
will have priority on any info registered on Global level 2 (spec ‘P’) or Contract level 3 (spec ‘E’).
Once the Mass Changes are successfully done, you have to Export these updated contracts (set
available flag to ‘Y’) because the mass change automatically sets the flag = 'N'
7.2.1 Comm. grid
This utility allows you to do a mass change on any of the fields related to commission grids. The
changes are done in FARES TEMPLATE database for all fares lines matching the selection criteria’s.
You first have to fill the required selection criteria on top of page. If you leave everything blank, it
will apply to all contracts.
- If you put an ‘x’ in a field, it will remove the information it contains. Available for all fields except
OW.
- In Agency $, cap $ and Mark-up, you can put the amount or the difference (+ or -) you want to
apply to the amount. Example: If you have a mark up of $50 and want to change it to $40 you can
enter either 40 or –10
- To set infant or child % to zero, you must enter 0.00
- Currency and Airline are fields related to group of fares. Make sure your selection criteria’s are
either contract and/or (gateway & destination). Any selection criteria’s related to specific fare lines
will not be taken under consideration.
7.2.2 Routing
This utility allows you to do a mass changes on routings. Changes are done in FARES TEMPLATE
You first have to fill the required selection criteria on top of page. At least one selection criteria is
required.
Important :
- If you check mark the Add box, it will add the routings to existing information.
- If you do not check mark the Add box, it will erase all existing routings for matching selection and
replace it with this new information.
- If you check mark the Delete box on the top part, it will delete all the routings related to the
- If you check mark the Delete box at the end of the routing, it will delete all the routings with the
same routing and via information.
This utility allows you to do a mass change on restricted flights. You can either add or delete
restricted flights. The changes are done in FARES TEMPLATE database for all fares lines matching
the selection criteria’s.
You first have to fill the required selection criteria on top of page. At least one selection criteria
must be selected.
To add restricted flights, airline and flight numbers must not match any existing entries (of selected
To delete restricted flights, airline and flight numbers must match existing entries (of selected
7.2.4 Open Jaw
This utility allows you to do a mass changes on Openjaws. Changes are done in FARES TEMPLATE
be selected.
Important :
- If you check mark the Add box, it will add the openjaw to existing information.
- If you do not check mark the Add box, it will erase all existing openjaws for matching selection
and replace it with this new information.
- To delete open jaw information zone, type, with zone and with type must match existing
information and delete box checked.
- Zone and Type must all be the same on each line.
7.2.5 Week-end
This utility allows you to do a mass changes on week-end surcharges. You can change, add or
delete week-end surcharges. Changes are done in FARES TEMPLATE database for all fares lines
matching the selection criteria’s.
be selected.
all fares that will match the selection criteria. To change information (amount and days) on existing
week-end surcharges, valid dates must match with existing entries.
To add week-end surcharges, valid dates must not match any existing entries (of selected
To delete week-end surcharges, valid dates must match existing entries (of selected information)
and delete box checked.
7.2.6 Black-Out
This utility allows you to do a mass changes on black out dates. You can add or delete black-out
dates. Changes are done in FARES TEMPLATE database for all fares lines matching the selection
criteria’s.
be selected.
To add black-out dates, valid dates and Out/in indicator must not match any existing entries (of
selected information) and delete box not checked.
To delete black-out dates, valid dates and Out-in indicator must match existing entries (of selected
7.2.7 Surcharge
This utility allows you to do a mass changes on surcharges. You can change, add or delete
surcharges. Changes are done in FARES TEMPLATE database for all fares lines matching the
be selected.
To change information (amounts) on existing surcharges, valid dates must match with existing
entries.
To add surcharges, valid dates must not match any existing entries (of selected information) and
delete box not checked.
To delete surcharges, valid dates must match existing entries (of selected information) and delete
box checked.
7.2.8 Rules
This utility allows you to do a mass changes on Rules. Changes are done in FARES TEMPLATE
be selected.
- If you put an ‘x’ in field (first character) , it will remove the information it contains.
- If you put an ‘X’ in all fields (first character), it will delete the whole table.
- If you leave a field blank, it will leave existing information. Therefore, if you put information in a
field, it will replace only the fields with new information.
7.3 Mass Change Contract
To mass change information in the contract table.
Because you can specify PCC information per contract ( for all negotiated fares for instance) we
have created this utility to facilitate the work. Contract table must be revised after creation of a new
contract (using Webfares directly or import of excel files), it contains important settings that are
contract related.
You simply have enter the information you wish to replace for all contracts that will match the
selection criteria.
Then you select the contracts that you wish to mass change and click on the plane.
7.4 Clean Zones
The Clean Zones utility is used to delete all unused zones. Zones on which no fares are attached.
This tool should be used on a regular basis (Example: once month) for database maintenance and
cleanup.
7.5 Delete Contract
The Delete Contract utility will delete all the fares related to a specific contract in the FARES
TEMPLATE database and their related specification tables. It will also delete the contract
identification in the scrolling list.
Use with caution!
7.6 Clone Contract
The Clone Contract utility is used to either:
Clone an already existing contract into ANOTHER contract.
OR
Copy existing information from a contract into other gat/dest in SAME contract
The bottom lines can be use ONLY if contract name from and to is the SAME.
You can copy from/to gateway and/or destination
For instance, if you have
Contract ABC with
YUL to YYC
YUL to YVR
YUL to YEG
and want to copy everything that originates from YUL into YYZ for same destinations, you could
COPY
from contract ABC to ABC
From gateway YUL to gateway YYZ
From destination (blank) to destination (blank)
And it will copy all the YUL to something into YYZ to something, therefore you will get:
YYZ to YYC
YYZ to YVR
YYZ to YEG
<<Previous page
7.7 Auto zone
To automatically create Gateway or Destination zones using Iata zone, country (or multiple
countries) and state code from the airport table. City codes if required must be manually added in
the zone once created.
Choose a zone type: Specify if you which to create a Gateway or Destination zone.
Choose Iata area zone(s): You can select 1 or more IATA zone. If you do select an IATA zone, the
country and states will not be offered. If you do not choose an IATA zone, system will continue and
ask you to select a country.
0 USA
1 Mexico
2 Caribbean
3 South America
4 Europe
5 Africa
6 Middle east
7 Fareast and India
8 Australia
9 Canada
Choose a country code: Select the country from which you want to obtain the airport codes that will
be part of your zone. Scrolling list is provided using country codes in airports table.
If you check mark the add another country box, you will be able to select another country.
You can select as many countries as you want.
If you choose multiple countries, states will not be offered.
Choose a state code: Currently only applies to US. This option will not be offered if you select
multiple countries. If you select only one country, then you will be able to select a specific state
from which you want to obtain the airport codes. Scrolling list is provided from airports table using
previously selected country code
If nothing selected, system will create zone with all airport codes for that country regardless of the
state.
<<Previous page

Web Fares Manag

Transcription

Similar documents

e-Fare™web based fare system

Cruise Holidays 5x88.indd - Cruise Holidays of Burlington

the implementation of successful social programmes in the provision

Secret Norway brochure

Proposed Xpress Route 423 Schedule, Fare, and Route:

Airline Reservation Hosting

2015 alaska cruises

Vista Travel Presents Cliqbook: Travel Management With A High IQ

Winnipeg Transit Guide

Save Crossing Hawaii off your list is easy