Forum programu Plaza

Aby poprawnie skonfigurować połączenie z Profitroom potrzebne są następujące dane:
Dane te otrzymujemy z Profitroom.

Teraz możemy przystąpić do skonfigurowania interefejsu.
Należy zadbać aby w katalogu DM Plaza była biblioteka pmailer.dll. Struktura bazy musi być zgodna z bieżąca wersją - istotna jest struktura tablicy oblozeniesync

1. Konfigurujemy moduł


Ustawiamy
Rezerwacja internetowa "profitroom"
Moduł aktywny na tym stanowisku
Na zakładce rezerwacja zdalna wypełniamy pola zgodnie z uzyskaną wcześniej informacją o połączeniu.


Ważne jest poprawne skonfigurowanie zarówno haseł, jak i interwału w którym dm plaza będzie wysyłać obłożenie do profitroom.
Pełna wysyłka oznacza całe obłożenie hotelu w zakresie x najbliższych miesięcy, a wysyłka zmian to wysłanie zmian w obłożeniu hotelu w porównaniu do poprzedniej wysyłki.
Najczęściej stosuje się wiele wysyłek cząstkowych w krótkim okresie i jedna wysyłkę pełną (np. co dobę, co 12h) w długim okresie (np 6 miesięcy).

2. Konfiguracja typów pokoi
Do typów pokoi przyporządkowujemy numer zewnętrzny typu.

Skąd taki numer zewnętrzny wziąć? Najprościej z profitroom,
Mnemoniki typów pokoi możemy otrzymać z panelu uppera lub wykonując polecenie:
uwaga:
[shadow=darkred]
[glow=red]polecenie to zwraca plik XML, zatem nie ma sensu wklepywać go w przeglądarkę. Musimy uzyskać źródło odpowiedzi (źródło strony)[/glow][/shadow]

Przykładowa odpowiedź: W obecnej chwili uaktualnienia allotmentu odbywają się tylko po InvCode (numer zewnętrzny jako liczba całkowita). Brak numeru zewn powodu brak wysyłki allotmentu. Jeśli korzystamy z mnemoników w profilu importu w pole"numer zewn." wpisujemy -1

3. Konfiguracja mnemoników w profilach importu.
Nie jest obowiązkowa, jeśli mamy do dyspozycji InvCode w postaci liczby. Jeśli mamy tylko jeden profil importu i invCode numeryczne, możemy invCode wpisać w pole numer zewnętrzny podczas definicji typu pokoju. W innym przypadku musimy skonfigurować profile importu.


4. Konfiguracja allotmentu.
Ten krok ma na celu określenie jaka liczba pokoi zostanie wystawiona do sprzedaży.
Allotment można konfigurować niezależnie dla każdego typu pokoju i zakresu czasu. Może istnieć zatem kilka konfiguracji dla każdego pokoju. Brak konfiguracji allotmentu powoduje wysyłkę zerowej dostępności pokoju.

5. Sprawdzenie
Eksport Allotmentu możemy sprawdzić w rezerwacjach. Proszę używać rozważnie na rzeczywistych bazach.
- Prześlij allotment obiektu do rez. online służy do przesłania całego allotmentu za dany okres do profitroom
- Aktualizuj zmiany w obłożeniu w rez. online wysyła tylko różnice w przesłanym allotmencie, a nowym stanem obłożenia. jeśli w tzw. międzyczasie nie było ruchu w hotelu, nie przesyła nic.
W tym samym menu możemy sprawdzić rezerwacje w profitroom dla każdego z profili importu niezależnie. Pobrane rezerwacje widoczne są w liście "Rezerwacje online" w module Recepcja.

Allotment jest wysyłany zawsze dla wszystkich profili.
Oczywiście po włączeniu automatycznej aktualizacji obłożenia korzystanie z tego menu nie jest konieczne.

6. Parametry pomocnicze.
RezerwacjeOnlineRodzajAkcji -Sprawdzanie rezerwacji online
-0 :ręcznie,
-1 :po zamknięciu doby,
-2 :co godzinę,
-3 :co 10 min.
RezerwacjeAktualizacjaOnlineRodzajAkcji -Aktualizacja zasobów online
-0 :ręcznie,
-1 :po zamknięciu doby,
-2 :co godzinę,
-3 :co 10 min.
Przy czym wybranie parametru 2,3 także spowoduje sprawdzenie raz na dobę jako wysyłki pełnej.
Np. możliwe jest ustawienie RezerwacjeOnlineRodzajAkcji=0 i RezerwacjeAktualizacjaOnlineRodzajAkcji =2, co spowoduje brak odczytu rezerwacji z profitroom, jedynie wysyłanie cząstkowych wartości obłożenia co godzinę i pełnego obłożenia raz na dobę.
Proszę pamiętac także o ustawieniu numer wersji Uppera w program.ini
np. poszczególne wersje zapytań różnią się od siebie np. potwierdzenia rezerwacji

7. Wiele profili importu.
W DM Plaza można zdefiniować wiele profili importu, każdy z odrębnym kodem hotelu i mnemonikami. Stosujemy takei rozwiązania gdy klient ma więcej nż jeden kanał rezerwacji.

Profile importu dla Profitroom muszą być typu OTA. Każdy z tych profili może mieć własny numer klienta, hasło , login i być wywoływany niezależnie (np. tylko na zadanie).
Profile dodadzą się do menu pobierania rezerwacji online (w liści rezerwacji). Gdy będziemy chcieli sprawdzić rezerwacje online, możemy to zrobić osobno dla każdego z profili. Automatyczne sprawdzanie rezerwacji, tak samo jak wysyłanie allotmentu odbywa się dla wszystkich profili jednocześnie.
W przypadku, gdy nie podamy numeru klienta dla profilu system będzie korzystał z globalnych ustawień modułu.
Dla pokoju, którego nie chcemy wysyłać w danym profilu NIE tworzymy profilu.

8. Znane błędy:
update_avail - błąd aktualizacji allotmentu. Najczęściej oznacza, że wysyłany mnemonik nie istnieje. Pamiętajmy, ze system najpierw sprawdza numer zewnętrzny, a potem profile. Aby numer zewnętrzny typu pokoju nie był brany pod uwagę należy wpisać "-1"
brak numer hotelu przy confirm bookings - błędny numer wersji Uppera. Należy zmienić na UPPER VER>=2

2016-04-16 is not a valid date - błąd formatu daty. Profitroom w komunikatach stosuje format daty zgodny ze standardem ISO, czyli YYYY-MM-DD. DMPlaza przy imporcie rezerwacji podstawia ten zapis pod datę w formacie określonym przez systemowy format daty krótkiej. Otrzymałem komunikat na serwerze, gdzie był on ustawiony na DD-MM-YYYY. Rozwiązanie: zmiana formatu daty krótkiej i restart Plazy.[/b]

jevkoo: Błąd został naprawiony

cancel_bookings_error - ?. Przy próbie operacji anulowania (zwykłego lub "anuluj rezerwację online"). Przy okazji pytanie, co Plaza robi, gdy rezerwacja na CRS jest wystawiona jako ResStatus="Cancel"? Bo wydaje mi się, że jest pobierana jak każda inna (ResStatus="Book")...


Odpowiedź jevkoo:
cancel_bookings_error może wystąpić przy błędnym lub pustym kodzie anulacji. Może też gdy wersja uppera jest niezgodna i np. dla wersji > 2 plaza nie wysyła hotelcode
ResStatus="Cancel" - sprawdzam od wersji 4373. Uwaga, w przypadku gdy włączony jest automat przenoszący online rezerwacje online do rezerwacji indywidualnych anuluje także ta rezerwację. Zatem zalecana ostrożność.

W związku z możliwością definiowania typów szczegółowych dodano możliwość aktualizacji obłożenia dla takich typów.

decyduje o tym parametr:
UpperAktualizacjaWOparciuOTypy
dla aktualizacji w oparciu o typy powinien mieć wartość 1
dla wykorzystania typów szczegółowych wartość 2

Jaka jest idea typu szczegółowego?
Czasami zdarza się, ze klient chce sprzedawać pokoje w aranżacjach lub wprost pokoje - nie typy pokoi. Jest to możliwe dla Uppera, natomiast Channel Manager w powiązaniu np z booking.com obsłuży tylko typ pokoju.
Zatem typ szczegółowy określa konkretną aranżację pokoju sprzedawana niezależnie w Upperze. W skrajnych przypadkach może nastąpić powiązanie każdego pokoju z konkretnym typem szczegółowym (np apartamenty).
Konfiguracja eksportu w oparciu o typy szczegółowe
Typy szczegółowe definiujemy prawie tak jak typy.


Ustawiamy parametr UpperAktualizacjaWOparciuOTypy=2

Aktualizacja bazy jest niezbędna.
Proszę zwrócić uwagę na zgodność struktury OBIEKTPOZ i OBLOZENIESYNC.
W przypadku tej ostatniej najprościej utworzyć ją od nowa - zmienia się główny indeks.
Definiujemy importy. Inaczej niż w przypadku importu dla typu pokoju potrzebne jest podanie dwóch wartości - typu i typu szczegółowego.

Weryfikacja dostępności pokoju przez profitroom

Weryfikacja zajętości odbywa się poprzez wysłanie zapytania przez profitroom do DM Plaza.
Zapytanie jest przechwytywane przez serwer HTTP połączony z bazą DM Plaza

Link wygląda następująco dla przykładowego klienta:
https://serwer.pl:11017/api/profitroom/ ... room=zzzzz
gdzie zzzzz to id pokoju profitroom zgodnie z
https://api.profitroom.pl/inventory_not ... lCode=9999
W odpowiedzi OK, gdy jest dostępność i NOT OK, gdy jej brak.
W chwili obecnej pozytywna odpowiedź będzie tylko w przypadku żądania typu GET.

Przykładowa odpowiedź dla pokoju DOMEK o ID=19584
https://serwer.pl:11017/api/profitroom/ ... room=19584

Hybryda dostępności.
Przypadek:
Klient sprzedaje apartamenty jako pojedyncze pokoje.
Niech to będą
APT1 Zielony 1 szt
APT1 Czerwony 1 szt
APT1 Żółty 1 szt
APT2 Zielony 1 szt
APT2 Czerwony 1 szt
APT3 Żółty 1 szt
jednocześnie na potrzeby portali ma w Profitroom stworzone sztuczne typy
APT1 3 szt
APT2 2 szt
APT3 1 szt

Chciałby aby na stronie internetowej można było sprzedać
APT1
i wtedy obłożenie zostałoby zmienione dla sztucznego typu APT1 i np APT1 Czerwony (pierwszy dostępny)
lub odwrotnie
aby na stronie internetowej można było sprzedać
APT1 Czerwony
i wtedy obłożenie zostałoby zmienione dla sztucznego typu APT1 i APT1 Czerwony.
Jest to dość skomplikowana sytuacja, która możemy rozwiązać tylko jeśli ustawimy
parametr włączający aktualizację w oparciu zarówno o typy szczegółowe jak i typy pokoi
UpperAktualizacjaWOparciuOTypy=3
parametr załączający aktualizację obłożenia po wykonaniu każdej zmiany w obłożeniu (zmiana musi aktualizować zarówno typ jak i typ szczegółowy) - profitroom tego nie robi.

Pozostaje nam ustawienie mnemoników zarówno dla typów jak i typów szczegółowych.
Uwaga - proszę pamiętać, że system będzie dysponować częścią wspólną obłożeń dla konkretnego pokoju. Dlatego tez szczególny nacisk proszę położyć na sprawdzenie, czy zakresy dostępności się nie nakładają.
RezerwacjeAktualizacjaOnlinePoRezerwacji=1

Kody pokoi w profitroom widzimy jak na obrazku poniżej:



Pokoje dostępne w online możemy zaznaczyć w definicji pokoi. Jest to niezbędne, aby liczba dostępnych pokoi była zgodna z liczbą dostępnych w Upperze.



parametr:
PotwierdzRezerwacjeOnlineAutomatycznie powoduje automatyczne przyjęcie rezerwacji online do rezerwacji indywidualnych
przyjmuje wartości:
0:brak,
1:dla rezerwacji dotyczącej typów szczegółowych
2:dla typów i typów szczegółowych

Uwaga - włączając parametr 2 należy liczyć się z fragmentacją rezerwacji.

Uwaga - teoretycznie jest możliwa sytuacja, gdy manewrując dostępnością w Upperze i nie aktualizując tej dostępności w DM Plaza możemy dostać drugą rezerwacje na ten sam pokój, na ten sam termin. System nie wyświetli żadnego komunikatu (batch mode), tylko przyjmie taką rezerwację jako niepotwierdzoną.

Udało mi się zasymulować powyższą sytuację wyłączając DM Plazę, włączając ręcznie dostępność w Upperze na konkretnym pokoju. Jako, ze system odbiera rezerwację w tle - nie wyświetla żadnych komunikatów powstała rezerwacja niepotwierdzona.
Oczywiście można zostawić ta rezerwację w online, ale recepcjonista tez tego nie sprawdzi.
Wydaje mi się, że żółta rezerwacja w normalnych rezerwacjach jest bardziej widoczna.

Czyli wiemy jak skonfigurować, czas na opis działania. Próbowałem połączyć moduł z CRS, nie BE, różnice są teoretycznie drobne.
Upper ver =1 to komunikacja BE "stara"
= 2 - CRS "stara"
= 3 - BE "nowa"?
= 4 - CRS "nowa"
= 5 - CRS szczegółowe typy pokoi
i tu już pierwsza uwaga: szczegółowe typy trzeba zapewne przełączyć zarówno zmieniając upper ver, jak i parametr UpperAktualizacjaWOparciuOTypy.

Wartości rezerwacji: rezerwacje są czytane do rezerwacji online ("bufor rezerwacji"), i dopiero stamtąd przenoszone do rezerwacji hotelowych. Dla CRS do niedawna (wersje z lutego?) w buforze rezerwacji była jeszcze informacja o wartości pobytów w rezerwacjach, ale po jej zaciągnięciu do zwykłych, już nie. Obecnie informacja jest przenoszona, ale w przypadku ręcznego przenoszenia rezerwacji - po włączeniu PotwierdzRezerwacjeOnlineAutomatycznie, wartości znów nie ma?

Ilość pokoi rezerwowanych: w CRS rezerwacja może obejmować wiele pokoi, jest odpowiednikiem grupy w DMPlaza. O ile wiem, BE to nie dotyczy. W komunikacji z CRS okazuje się jednak, że gość rezerwuje np. 10 pokoi, a do Plazy wpada nam rezerwacja na jeden pokój. Overbooking gwarantowany, o czym dowiemy się, gdy gości pojawi się w hotelu.

Anulacje rezerwacji: jak widać w opisie powyżej, anulacje są w ogóle sprawdzane od v.4373. W starszych - była po prostu kolejną rezerwacją(?). Teraz, jeśli Plaza trafi na anulację rezerwacji, której nie może anulować (nie znajdzie jej w bazie), nie przejdzie do kolejnych zapisów. Przy czym najpierw przyjmuje rezerwacje, później wykonuje anulacje, więc pojwią się nowe rezerwacje, stare nie zostaną anulowane. Overbooking, którego potwncjalnie być nie powinno. A przecież CRS wystawia informację tak ładnie: najpierw anulacje, później rezerwacje.

Modyfikacje rezerwacji: w razie modyfikacji rezerwacji, CRS ją anuluje i wprowadza na nowo. DMPlaza importuje jednak najpierw rezerwację, później anulację. Zatem, jeśli zmieniona rezerwacja nie znajdzie wolnego pokoju, to będzie wczytana jako rezerwacja niepotwierdzona, później pierwotna zostanie anulowana. Overbooking jak nic, patrz niżej: dostępność.
CRS wystawia jednorazowo 100 zgłoszeń (rezerwacje + anulacje; do niedawna było 50), które są zdejmowane z kolejki tyko po otrzymaniu odpowiedniego komunikatu. Wysłanie komunikatu dla rezerwacji raczej wychodzi, natomiast anulacje bardzo lubią się powiesić. Pierwsza problematyczna blokuje pozostałe. Można robić to ręcznie - ale pamiętajmy, w oknie bufora do zatwierdzenia anulacji służy inny przycisk, niż do zatwierdzenia rezerwacji.

Dostępność: REZERWACJE NIEPOTWIERDZONE NIE ZAJMUJĄ POKOJU! Jakiś czas temu (nie wiem, w której konkretnie wersji) przestał działać parametr odpowiadający za to, jak traktowane są rezerwacje niepotwierdzone. Od konfiguracji zależało, czy były liczone jako pokoje zajęte, czy nie, aż od pewnego dnia po prostu przestały być liczone do zajętych (no nie do końca - stare rezerwacje niepotwierdzone miały REZERWACJA.REZERWACJA_STATUS zgodny z parametrem, dopiero nowe dostawały 0, więc robił się bałagan). No i będzie overbooking.
Dostępność w nowych wersjach DMPlaza (około września 2015 i nowsze, czyli te z "nową tablicą OBLOZENIESYNC) jest obliczana w oparciu o OBLOZENIE. Co to oznacza? Oblozenie ma informacje o pokojach zajętych. Jeśli w jakimś dniu nie ma żadnej rezerwacji, meldunku ani remontu, to taki dzień w obłożeniu nie istnieje. Dostępność jest wyliczana dla dni z oblozenia => dostępności dla "pustych dni" (a także dni z samymi rezerwacjami niepotwierdzonymi) po prostu nie ma, więc zapewne nie jest wysyłana. Czyli hotel stoi pusty, a do CRS informacji o pełnej dostępności nie wysyłamy? Anulując ostatnią rezerwację na dany dzień nie aktualizujemy jego dostępności? Ponadto pamiętamy, że obłożenie się w DMPlaza potrafi wysypać (patrz tutaj).
Rezerwacje zakładane bezpośrednio w DMPlaza - odsyłają informację o zmianie dostępności pokoju w ustalonym interwale czasowym. Czyli zakładam grupę na cały hotel, a dostępność w CRS do kolejnej aktualizacji (3h? 6h?) jest niezmieniona, pokoje dostępne. Będzie overbooking, chyba że po założeniu rezerwacji ręcznie przeklikam przez www dostępność CRS.

Konfiguracja: dane dostępowe do CRS podajemy w dwóch miejscach: w konfiguracji biblioteki pMailer.dll oraz w konfiguracji profilu importu. Wg moich testów, Plaza czyta oba te miejsca: jedną konfiguracją czyta przy pobieraniu rezerwacji, drugą przy odsyłaniu potwierdzenia.

Czyli, "pół-ręcznie": pobrać rezerwacje do bufora, stamtąd wklikać je ręcznie do Plazy (zatwierdzić lub zaklikać anulację, zależnie do rodzaju zgłoszenia); dla rezerwacji na kilka pokoi zatwierdzić je kilkukrotnie (tip: czytać uwagi, tam jest informacja o ilości i typach pokoi). Po takiej operacji wejść na www zarządzania CRS i zaktualizować dostępność dla odpowiedniego okresu. To wszystko na odpowiedniej wersji DMPlaza oraz dodatkowym mocnym oskryptowaniu bazy pod kątem zapisów dotyczących cen (CRS podaje dla rezerwacji ceny na każdy dzień, czyli plazowe Plany cenowe). I u kilku klientów tak działa...
Pełny Automat odradzam tym bardziej - włączyłem u klienta na próbę, działał 2-3 dni. Po uruchomieniu pobrałem rezerwacje w trybie "ręcznym", aby wykonać wstępną synchronizację - pobrać rezerwacje z CRS, wywalić te, które recepcja już wpisała z maili, jednocześnie zdajmując je z kolejki po stronie CRS. Tu wyszło na to, że dla rezerwacji trzeba zrobić zatwierdzenie (3 kliknięcia dla każdej; więcej gdy wg opisu ma być kilka pokoi), zaś dla anulacji - bodajże "anuluj rezerwację online". Gdy to już było, włączyłem automatyczne potwierdzanie rezerwacji. No i po dwóch dniach się okazało, że nowe rezerwacje nie dostają cen, trzeba było je przeklikać ręcznie; że anulacja (wykoanana w DMPlaza!) dalej czeka w kolejce CRS (czyli nie poszło do niej potwierdzenie), i kolejne nie są w związku z tym czytane/przetwarzane. Powrót do ręcznego klikania, później weryfikacja dostępności. Overbooking wszędzie, gdzie były modyfikacje rezerwacji. Jeśli w hotelu z 20.pokojami w dwa dni wpadło ok 500 zgłoszeń z CRS, to automat jest porzebny. Jednak sprzątania było lekko licząc tydzień - bo trzeba bylo sprawdzić i poprawić całą dostępność w CRS.

Z interfejsem BE teoretycznie jest lepiej, bo nie wysyła rezerwacji na więcej niż jeden pokój w pojedynczym zgłoszeniu, i nieco inaczej wygląda procedure anulacji rezerwacji. Ponadto BE ma mniejszy zasięg , bo to tylko jeden kanał, podczas gdy CRS to integrator. Niemniej niewłaściwe obliczanie dostępności dotyczy całego interfejsu Profitroom, jak również prawdopodobnie interfejsu YeldPlanet. Ten ostatni zresztą jest oparty o specyfikacje OTA, więc teoretycznie również pozwala na rezerwację kilku pokoi w jednym zamówieniu - jego nie konfigurowałem, więc ciężko mi się wypowiadać.

Dodano nowy sposób odpytywania profitroom, oznaczony jako 6
Wymaga biblioteki: Dla połączeń HTTPS niezbędne są blibioteki

Uwaga:
parametry
UpperAktualizacjaWOparciuOTypy=3 (typy szczegółowe i ogólne)
i
EBookingWykorzystujProcedureAvail =1
są wykluczające się
dla EBookingWykorzystujProcedureAvail
UpperAktualizacjaWOparciuOTypy może przyjmować wartości od 0 do 2

Uwaga:
w DM Plaza 2019 komunikacja wszystkich interfejsów online odbywa się przez biblioteki:
BookingEnginesAPI.dll
BookingEnginesAPI.XmlSerializers.dll
FirebirdSql.Data.FirebirdClient.dll

Ważna modyfikacja. Tylko biblioteki dla DM Plaza 2019/22 obsługują nowy sposób komunikacji Profitroom oparty o TLS 1.2.
Aby z niego korzystać należy ustawić parametry:
EBookingWykorzystujProcedureAvail =1
EBookingYielPlanetDllPresent =2

w katalogu DM Plaza powinny być biblioteki: Sposób ustawienia profilu pokazuje poniższy rysunek.



Biblioteka zawiera również zmiany dotyczące anulowanych i modyfikowanych rezerwacji. Dzięki temu modyfikacja nie tworzy nowego wpisu jedynie koryguje poprzedni.

Uwaga ważne - jeśli nie korzystamy z typu szczegółowego dla importu to pole "Dla typu szczegółowego" musi być puste. Wykluczone są wpisy np zero, powtórzenie wpisu z typu ogólnego lub "-1" (dość popularne).

Uwaga ważne - jeśli nie korzystamy z typu szczegółowego dla importu to pole "Dla typu szczegółowego" musi być puste. Wykluczone są wpisy np zero, powtórzenie wpisu z typu ogólnego lub "-1" (dość popularne).

Powyższe wynika z warunków przyjętych w procedurach zliczających dostępne pokoje. Osoba konfigurując dostępność musi się pogimnastykować, ponieważ:
1. OBIEKTPOZ.POKOJPODTYP_ID jest NOT NULL, i aktualizacja programu tego nie zmienia
2. warunek NOT NULL nie jest nazwany, więc trzeba go najpierw odnaleźć w metadanych aby go usunąć
3. Od tablicy zależne są procedury (REC_ILEPOZ_OBIEKT oraz REC_ILEPOZ_OBIEKTTYP), więc aby usunąć tablicę, trzeba najpierw je usunąć, a później samą tablicę.
4. Po odtworzeniu tablicy oraz procedur okazuje się, że POKOJPODTYP_ID i tak ma warunek NOT NULL (DMPlaza 5095)
5. Gdy już pozbędziemy się warunku NOT NULL i dodamy wpisy, okaże się, że Plaza i tak nadaje wartość -1 dla pola POKOJPODTYP_ID, jesli nie wyczyścisz pola (ikonka).

Obecnie najłatwiej rozwiązać problem następująco:
1. na początku konfiguracji wykonać: 2. Po skonfigurowaniu wykonać:
W tablicy są pola OBIEKTPOZ_POKOJPODTYP_ID oraz POKOJPODTYP_ID. Tu pod uwagę wziąłem POKOJPODTYP_ID, jako problematyczneprzy definiowaniu dostępności. Czy i gdzie wykorzystywane jest drugie z nich (OBIEKTPOZ_POKOJPODTYP_ID)? Temat na inną okazję.

Po najnowszych poprawkach trzeba ustawić parameter EBookingDodajPobytJakoUsluge = 1. Przy ustawieniu 0 Plaza pobiera ceny poszczególnych dni jako składniki planu cenowego, ale dla każdego dnia zakłada je z datą początkową równą dacie końcowej, a takich składników z kolei nie nalicza wartościowo. W efekcie pobrane rezerwacje mają niepoprawne wartości. Z kolei po zmianie tracimy funkcję kontroli planu cenowego (czy pokrywa cały termin rezerwacji), co jest problematyczne w razie ręcznego przedłużenia takiej rezerwacji już w hotelu.

Alternatywą jest załatanie sobie bazy tak, aby plan cenowy miał zakładane poprawnie składniki.

W przypadku korzystania z serwisu booking engines nie zalecamy, aby jednocześnie pobierać rezerwacje na stanowiskach klienckich za pomocą programu Plaza.
Oczywiście można pobrać rezerwacje co jakiś czas, aczkolwiek dublowanie pracy obu systemów może spowodować wzajemne blokowanie.BE powinien być zainstalowany na serwerze, nie na stacji klienckiej.
Przy zastosowaniu BE, można także pobierać rezerwacje bezpośrednio z samego serwisu.

Dodano mechanizm automatycznego przenoszenia rezerwacji online do rezerwacji indywidualnych.

Zasada działania mechanizmu opiera się na działaniu serwisu odczytującego na serwerze (bookingEngines) i automatycznym przyjęciu rezerwacji online do rezerwacji indywidualnych, kiedy ona się pojawi. Za ostatnią część odpowiada zapadka wyzwalająca procedurę REC_DODAJ_REZERWACJE_Z_ONLINE.

Rezerwacja zostanie przyjęta jednak tylko wtedy, jeśli wybrany pokój i typ pokoju są w danym okresie wolne. W przypadku konieczności przydzielenia innego pokoju niż zamówiony – nadal będzie czekała na decyzję operatora.

Mechanizm nie dopisuje nowego gościa do listy gości, chyba że gość już był w hotelu. W innym przypadku dopisanie do listy gości nastąpi automatycznie dopiero w momencie wystawienia pierwszego dokumentu płatności. Dzieje się tak, gdyż booking.com za każdym razem przyporządkowuje inny adres email gościom i nie ma możliwości jednoznacznej weryfikacji danych tylko na podstawie nazwiska, imienia i adresu email.

W przypadku zakupienia przez gościa online dodatkowych usług, zostaną one także dopisane do rezerwacji.
Gdy cena na każdy dzień jest różna, znajdą Państwo te wartości w zakładce „ceny: w formularzu rezerwacji.

Uwaga: REC_DODAJ_REZERWACJE_Z_ONLINE występuje w dwóch wersjach. Ze względu na odgraniczenia triggera w Firebird prosze wybrać procedurę NIE zwracającą wyniku. Procedurę z wynikiem stosujemy do "normalnego" przyjmowania rezerwacji.

Trigger nie jest obowiązkowy jeśli korzystamy z serwisu BookingEngines - wtedy dodanie zależne jest od parametru RezerwacjeAktualizacjaOnlinePoRezerwacji

Użytkownikiem, który doda rezerwację online jest użytkownik, który ma w nazwie "ONLINE" (dowolna wielkość znaków). Jeśli nie ma takiego użytkownika zostanie wybrany ostatni aktywny w systemie.