Release Notes 1048
Content
*1* *DaVinci*\
1.1 Flights \
1.2 Bus \
1.3 General \
1.4 Package Price Calculation \
1.5 Interfaces \
1.6 Hitchhiker \

DaVinci

Flights

Function mode of the batch action
Via the batch action „flight information update " it is possible to update changes in the flight information (rotations), as flight times or flight number in all reservations which are affected.
The action is reachable over the menu bar in the genesis mask

It is possible to select a reservation code for a certain achievement period.

Through click on „start "in all reservations with the adjusted selection parameters, the flight information for the selected reservation code will be updated



The information is deposited in the rotation

And in the booking at the reservation code are stored here

Setting of a „X "in the first column (manual) of the flight information in the procedure causes that no automatic actualization of the flight information takes place here, in order not to overwrite possible manual inputs.




Manual inputs in the flight information
For scheduled flights, which are booked over Amadeus, the respective file keys must be registered manually into the flight information of the reservation code in the reservation.
For this the" X" is set at "manual" and the file key has to fill in into the intended field.

Problem and setting of tasks
Due to logic, that flight information are dated up at reservations, in which the "X" is set at "manual" in the flight information and these no more run over the batch, is not (longer) possible to update the flight information about the batch action after input of the file key into the reservation for this achievement in this reservation.
From this the following problem results: flights - which are already booked and with which the file key was registered into the reservation - an additional flying time or changes of flight number are not able to be updated any longer.
So, this change cannot communicate to the guests and also the wrong (outdated) information will be proofed on the travel documents.
A possibility must be created that flight information can be updated about the batch action, although file keys were registered already manually in the flight information.


ONLY the fields are to be updated, which are maintained also in the flight rotation.

The following changes are suggested on the part of Bewotec:

1. Adjustment in genesis: A new flag has to be taken up in the batch-"Flight rebooking" with „also manual segments to update ".

If this flag is set beside the normal segments also the manual are overwritten/deleted and additionally the file key will be take over.

1. Exactly, as with segments where the manually flag is not set, all segments of the found flights will be always deleted and filled again by the rotation data.
2. Only at flights, where the manually flag is set, the file key will be taken over. With the assumption of the file key it will be difficult to find a clean solution, which takes off all cases. Our proposal would be:

a. The file keys will be written in the same order and to the same position written as up to know, example:
Change of flight time

or change of routing

b. If a segment drops out, also the appropriate file key is not any longer assigned, example:
OLD                                                                           NEW

c .If a segment comes in addition, the last file key is also transferred to the new segments, example:

Bus

Create Return route to existing bus route
We need the ability to create automatically a bus return route to an outward route so that entry of master data will be easier and faster


In current sample new route "LYSZ1H_RET" (description "Busanreise Lyon Zone 1 Return") should be created including all properties and 3 lines for "RKO", "RFR" and "PRI" with all properties except time (time should be set to 0).

Now it is possible to see the seat map of the selected bus in an overview. Changing a seat in the previous functionality will be shown in the seat map afterwards.

The entry and exit locations for bus routes are multi-lingual. This results in multiple entries for the same type.
Additional the description and information in the assignment of an entry/exit point to a route is multi-lingual.
DESCRIPTION
Center
Zentrum
Centrum
Centro
Centre
CITY
Venice
Venedig
Benátky
Venecia
Venise

It is now possible to store an entry or exit point without a timestamp. In specific reports this will be interpreted as no known time.

General

Batch process kickback contracts
Former situation
Each Kick Back contract has to be separately (manually) processed.

Current situation
Enable multi-selection for Kick Back calculation (creation of NR bookings).
It should be possible to calculate multiple Kick Back contracts (creation NR bookings) in one step; kind of batch processing.
Multi-selection of contracts should be enabled via STRG.

The batch-KickBack-calculation should be initiated via new context menu entry „Kickbackberechnung im Batch"/"Kickback calculation in batch".
The calculation has to automatically create NT bookings for all contracts with commission > 0.
In case of contracts with commission <= 0 the system must not create NR bookings.

If clients send E-Mails out of DaVinci via E-Mail templates, there is no title for the client in the E-Mail object available.
Example:
Betreff: Buchungsnummer : 278420 Kunde: Klinger
Sehr geehrter Herr Klinger!
Vielen Dank für Ihre Buchung! In der Anlage erhalten Sie...



The salutation is now available as variable <BO_CLIENTSALUTATION> which differs between "Sehr geehrter Herr" und "Sehr geehrte Frau".
But in the object of the E-Mail only Herr or Frau is needed. So there needs to be a variable like <BO_CLIENTSALUTATION_2> developed for this.
Additionally a client title is needed, which makes it possible to add the academic title of a client. This could be: <BO_CLIENTTITLE>
This information should be taken from the client data:




So if the development is done, it should look like this:
Betreff: Buchungsnummer : 278420 Kunde: Herr Dipl.Ing. Klinger

It is now possible to combine booking and client address selection criteria within the new client/address search in DaVinci.
 
The upper area strictly worked address related and the down area booking related. It was not possible to combine criteria form both views.
Now it is possible to define both lists considering criteria of both lists.
E.g. all client addresses should be displays which are booked for agency 1 and in travel destination "DON".

If the flag catalog not show in DaVinci is set, in former versions the bookings from that catalogue in the search were hidden as well. Now the bookings are visible in the search, else catalogue is archived.

Go to Ausgabe > Externe Dokumente:

And search
You will get this screen:



Go to properties or add new one:

In this dialog there is a new filter criteria (Vorgangskriterien):
Booking Status => like it is already in other dialogs e.g. in filter sets:

It is now possible to book with package code and slash for flight destination code, even when the package is stored with a one way flight so that package will be extended and booking will be easy. In former versions this was only possible for a return flight. To use this functionality it is necessary to set the right flag in the basic data settings.
 
Basic Data settings line 7 + 8

Size is 20 characters.

• Catalog--price rule assignments
• Price chart heads- price rule assignments
• Sub price chart--price rule assignments
• Price line-- price rule assignments

The new entry needs to be printed on enabled print documents later on (additional report task).

Transfer posting barrier for achievement period does not work during simultaneous transfer posting on other reservation code.







The following dynamic rule is activated:

If the travel date and also the reservation code should be changed at the same time, this rule does not functions any more (requirement K remains).
Example:
From: KTUIC15.07.2010 bis 25.07.2010
Rebooking to: KTUIC26.10.2010 bis 05.11.2010
=> ERROR IS RELEASED
But:
From: KTUIC15.07.2010 bis 25.07.2010
Rebooking to: KMEINS26.10.2010 bis 15.11.2010
==> NO ERROR IS RELEASED



In addition, in the 2nd case an error is to be released.
The dynamic set of rules has to be extended in such a way, that a change of reservation codes (which reservation code should be able to be defined in the set of rules) can be prevented on another reservation code by the release of an error.
New Rule:

Description
Extend Master data tracking to cover more of the settings – Conditions.
There are many settings more covered by the master data tracker, that prevent a risk for Tour Operators if something has been changed.
Former situation:
Only price rule definitions are included in the master data tracking from the conditions.
New Situation:
Enable more of the conditions to the master data tracking
Commission chart
Rebate chart
Cancellation chart
Booking change
Rule groups
Price rule category
Handling fee
price calculation parameter

Description
Ability to define different display colours for the different booking states, in the booking code search result dialog
Development Concept
Add the ability to assign a colour for the different booking states that shall be shown when searching booking codes
Former situation:
All booking codes possessed the same colour in the booking code search results

New Situation:
Have ability to assign a color to the booking state then when it is displayed in the search results user can identify quickly what is the state of that booking code.

• A warning can be stored on folder level
• The warning applies for all products stored on all subfolder levels underneath the corresponding folder
• The warning appears in Genesis and also in all other surrounding systems where a warning is displayed (CETS)

a) behaviour of bookability settings in warnings, stored on folder level is the same like the bookability settings in warnings stored on catalogue level.
b) External systems (i. e. CETS / internet booking engines) should handle the bookability status stored on the folder in the same way like the bookability status stored on system calatogue level.
Example:

1. Check bookability state on catalogue level = bookable
2. Check " on booking code level = bookable
3. Check " on folder level = fully blocked

• Products stored underneath a folder that is set to fully blocked by a warning should not be bookable in Genesis

• Products stored underneath a folder that is set to fully blocked by a warning should not be bookable via any other booking interface (CETS)

Since version 1046 it is possible to have Daily prices in DaVinci. In the GUI this was solved by using virtual season terms and new columns to indicate different tiers in prices and allotments.
Tier pricing reflects the business when a tour operator has sold a certain allotment to a certain price. Then it can be that he again contract with the hotel new allotments for a certain price.
This concept describes what areas in DaVinci have to be modified to support the creation, maintaining and working with tier pricing in DaVinci.
Allotment day:



Show the different tiers in allotment frame.
The naming is Tier A, Tier B, Tier C, Tier D
Display here the values from allotment day/section Tier. As this is a free definable label Tier A is the first, B the second etc. value.
The total will be here 25. This will not change.
Wizard Change allotments
It should be possible to add a certain amount of tier allotments for a certain date range


Here I want to add 5 allotments, but 1 Tier A and 1 Tier B.
In fact, the system overwrites existing Tier values. This could be a huge problem because then you have to maintain your allotments day by day and not for a period.
There should be following possibilities:

• Update number of tier allotments with +,- and total

Pricing


You can create a price chart with setting "Day price" then you can just link virtual season table. This season table has just one season term because you do not need seasons for daily prices in this concept. As DV needs something it was decided to use virtual season terms.





If you then change into price matrix you can add only one price row automatically.




Price matrix
For tier prices you can indicate different valid departure dates with following:


And here lies a usability problem if you have 365 entries or more if you work with further rules linked to price detail or tiers linked to price detail:

Following further possibilities needs to be created:

• Sort by header
• Copy Rows

Conversion EK/VK/Editing Prices
The valid dates are missing completely that means the user cannot see when a daily price is valid. Moreover you cannot see the tier.


Following possibilities needs to be amended:

• Show 3 new entries between "Betrag From" and "Regel To" in this dialog

Tier Code

Valid from + Valid to

• Change the fix sorting by sort additionally Tier, Valid from

Price details


Following further possibilities needs to be created:

• Sort by header
• Copy Rows

The flag in line 7 is now working in the correct way as described. Before version 1048 it was out of functionality. All DaVinci users should check, if the flag is on or off. In the case it is hooked, be aware of different behavior.

Changes in BSP Import
Description:
1. There should be an additional column "Payable amount" in the dialogue of "BSP – Error list", which sums up fare + tax – comm. – comm. tax
2. New columns "Payable Amount BSP" and "Payable Amount DaVinci"
3. Comparison concerning the difference in "BSP Statistic" is only payable amount.

• Konfiguration => Import/Export => Import BSP-Daten:

• Fehler bearbeiten

1. There is an additional column with „Payable Amount" in this dialogue!
Like in the "Statistik"/ Tab Total dialogue:

The "Payable Amount": calculation should follow the same logic like "payable amount" in statistic in tab TOTAL!!!
So it contains the same values like the sums, see 2.

2.
There are new columns in this dialogue:
Payable Amount BSP + Payable Amount DaVinci

The calculation of these amounts should follow the same logic like "payable amount" in Statistic/ Tab total.

3.
If there is any difference between the "payable amounts" (new columns from 1 and 2) in BSP and DaVinci there should come up an error!
The difference which is shown in the error list in column "difference" is the difference between "Payable Amount BSP" and "Payable Amount DaVinci".

If there are also any differences in other fields (fare, tax, commission...) there should also come up errors in the error list. So there is no need to change.
So it can be that there is no difference between the two sum amounts, but i.e. a difference on fare and com. For these there will be an error listed, but difference will be at 0.

Description:

In the tables of prices, it is possible to deposit prices under the impacts in dependency of the posting date.

Over the drop-down-box in the field "Valid" can be selected, whether that
to this impact defined posting date in the fields „reservation of "and „reservation to " is valid for the posting date of the booking or the posting date of the service.


This possibility does not exist for the basic prices in the upper range. There also can be deposited „a posting date of" and „a posting date to", however the attitude possibility does not exist, whether this date is valid for the posting date of the booking or the posting date of the service.
Always, this date is overall valid for the posting date of the service.

Here is now a possibility to deposit a price, whose date is valid for the posting date of the booking.

Description:
There is a new functionality in „copy price to all seasons" where you can select if you always want to copy the prices or if you only want to copy them to season which are empty.
It worked like in elder versions (e.g.1039).




Before copying:




After copying:

Now there are two basic prices in the price/season table.
It doesn´t matter if there are any prices existing or not.











New development:
Now it is possible to copy the price to all empty seasons (where is no price).Therefore there should be a new menu after selecting "Copy price to all season" like described in the screenshot below, where you can select : "always" or "only if doesn´t exist":

Package Price Calculation

Description
In package price calculation, it is required to increase the functionality to include a batch calculation priority.
Increase the PPK menu to include the ability to assign a batch calculation priority. This Priority will not be used for online calculations and storage, but for the calculation type's batch, batch and store, and the Batch store selections.
Former situation:
PPK menu:






Developed Situation:
Menu: Increase to possess dropdown of priority

This priority will be stored in the table CALC_PARAMS, in a new column i.e. CP_PRIORITY:
Values that will be possible to select are NULL (Default (Blank)), and priorites.
The priority field will be reseted after calculation.
Batch Calculation logic change
During the batch calculation application, will have an adjustment to its loading logic. All packages defined to be caluclated in batch, batch calculate and store... will be loaded, as usual. What will be new is that after each package is calculated, since all are, currently, calculated in a sequencial order, will be a refresh/recheck for any changes, in priority status. In this way, the batch calculation tool does not have to be stopped to refresh the priority state of packages. After each package calculation system will check the states, and load the next highest priority package for calculation.

Description
Ability to search in the price calculation frame
Concept
Add the ability to filter text in the price calculation definitions
Former situation:
Currently, the only means to find a defined calculation definition is via scrolling through the list of defined price calculations, or via filter. Both are time consuming.
New Situation:
Enabled the ability to filter rows using a text string; for name and description of a price schema
This allows a user to quickly display rows that meet specific criteria without having to compare each individual row to see if the row should be displayed.
The users can utililize the filter feature to specify only rows with a specified text string will be displayed

Interfaces

1.) In case auf Austrian tour operators (bank details)

• No checks of bank details (account number and BLZ) should be executed
• No DTAUs file should be created

Discussed solution:
One new flag "Create DTAUS file" / "Erstellen DTAUS Datei" within the export dialog. In case the flag is enabled (default) the DTAUS file plus client payments will be created. In case the flag is disabled only the client payments will be created.
The export dialog should be renamed to "Export (autom. payments) "Export (autom. Zahlungen)"
In case the export flag is enabled all entries with invalid BLZ numbers (have to be exactly 8 characters) will be lighted.

1. Date
2. Similar to B&S export it shouldn't be distinguished any more between 'Lastschriften" and 'Gutschriften". Please skip drop down.

Both should be exported. Selection criteria (date) should also be same than in B&S.
3.) Similar to Commission Payment Export only one entry per agency should be exported with total.
Instead of text e.g. "PROV 01.11.2010-30.11.2010" please export "Zahl 01.11.2010-30.11.2010".
Only bookings with agency collection should be considered.
Tour Operator collection bookings should be considered like now (one entry per booking).




4.) Similar to Commission payment Export the possibility is needed to send (print/mail) an Avis document (report) per agency.
Only bookings with agency collection should be considered.
No Avis for Tour Operator Collection bookings.
Same report entry than for commission payment s. Rename report entry. Store focus on export dialogs.


Commission Payments

5.) Additionally to the Avis it has to be possible to print a simple list of the exported payments (kind of "accompanying document").
Sample:

The list should contain one line per payment including amount, bank details and description.

The new Logging-Feature is now available. From now on the old Logging is no longer available. No GenVasProc.log or other log files. Everything will be saved into a Database (BewoLogging). Xml-Files can still be generated as already known from old logging. For further information, please contact Bewotec.

Hitchhiker

Offer Booking process
Booking
The new workflow for offer bookings:

If a request for an offer including external flights (HH) was sent, the user has to select the specific flight combination from the transport search. If the transport search was not used for flight search initially before sending "AA" or "A" it will now open automatically.



The transport search will be executed automatically based on the information entered in Genesis. (Date from, Date to, departure and arrival airport.)

When the user marks an outbound flight, all the inbound flights which are not combinable are greyed out and only the combinable flights are shown with white background for selection.

If the user selects a greyed out inbound flight, all not combinable outbound flights will be greyed out. Only the outbound flights with a white background are combinable for selection. After selecting a valid flight combination the user can apply the selection to genesis.

The offer is created with action "A" and the flight information is stored in the booking. No PNR will be created in the GDS.

The outbound flight information is stored in the properties of the booked outbound service.

The inbound flight information is stored in the properties of the booked inbound service.
Rebooking

The travel time is this booking file is from 02.11.2011 till 08.11.2011.


Now the user changes the departure to 04.11.2011 and executes a rebooking request.


The rebooking action will not be possible as the flights have to be selected again in the transport search. Now the transport search will open automatically with the information originally entered.

The search will be executed. As in this case the inbound flight was not changed in Genesis, it will be marked automatically (if still available) in the transport search. The user selects a new outbound flight and applies the changes to Genesis.


Now the rebooking can be executed and the new flight information is stored in the service lines.


Fix Offer Booking

An existing offer can be fixed with action "AF".


In the original offer booking file the outbound flight information is stored in the properties of the booked outbound service.


The inbound flight information is stored in the properties of the booked inbound service.

When the user tries to fix the offer by entering command 'AF'the transport search dialogue will open automatically.

The flights which had been stored in the offer booking will be pre-selected in the transport search result if they are still bookable. If the flights are not available anymore no flight will be pre-selected and the user needs to make a new choice.

After applying the flights to Genesis the offer can be fixed and a PNR will be created via Hitchhiker in the background.

The created PNR will be displayed in the external reservation number.
Option from offer

An existing offer can be changed to an optional booking with action "AO".

In the original offer booking file the outbound flight information is stored in the properties of the booked outbound service.

The inbound flight information is stored in the properties of the booked inbound service.


When the user tries to change the offer to an option by using command 'AO' the transport search dialogue will open automatically.

The flights which had been stored in the offer booking will be pre-selected in the transport search result if they are still bookable. If the flights are not available anymore no flight will be pre-selected and the user needs to make a new choice.

After applying the flights to Genesis the offer can be fixed and a PNR will be created via Hitchhiker in the background.

The flight information is stored and the PNR is in this case "VJ29JM".

Cancellation


A cancellation can always be executed for an offer. No external action will take place as no PNR was booked.