Подобрения
Клиентски дисплей
При попълването и подписването на регистрационната карта от госта чрез Клиентския дисплей, обърнахме специално внимание на имейл адреса на госта. Аналогично на Online Check-in и Киоска, ако имейл адресът на госта е маскиран от онлайн портал, изрично се изисква въвеждането на реалния имейл адрес на госта.
Ако регистрационната карта вече е подписана електронно (чрез Online Check-in, Киоска или самия Клиентски дисплей), екранът с хотелската политика се пропуска и не се изисква повторен подпис. По този начин клиентският дисплей позволява още по-бързо и удобно събиране на допълнителна лична информация от госта, като имейл адрес, телефонен номер, причина за посещението и др.
На последната стъпка (преглед на политиката, данните и подписване) вече се използва хотелската политика от регистрационната карта, а не общата хотелска политика, както беше досега.
Подобрихме обратната връзка към служителя. Когато гостът попълни данните в регистрационната си карта, те се визуализират незабавно на екрана на служителя. Освен това се появява известие, което привлича вниманието му към въведената информация.
Други подобрения
Online Check-in – добавихме проверка, която не допуска регистрирането на няколко гости с една и съща лична карта или паспорт (аналогично на Check-in Kiosk). Уточняваме, че изискването за броя на регистрационните карти подлежи на настройка. Можете да изберете дали да се изисква една регистрационна карта за цялата резервация, по една за всеки възрастен или по една за всеки гост, включително децата.
POS – при използване на опцията за трансфер на сметки към компания в PMS, оптимизирахме зареждането на списъка с компании, така че дори при голям брой компании зареждането да бъде бързо.
D-EDGE – миграция към A2021. Поради прекратяването на поддръжката на предишната версия на протокола, D-EDGE изиска преминаване към по-новата версия A2021. Няма съществени промени във функционалността на интерфейса. Ето подробностите:
Експорт – ако не е зададен максимален престой, се подава MaxStay = 0 вместо 99, както беше досега.
Допълнителни услуги – към поддържания модел на начисляване на допълнителни услуги (PerNight) добавихме още три модела:
PerStay – начислява се при пристигане.
PerGuest – количеството се изчислява по формулата количество = брой гости × количество.
PerGuestPerNight – аналогично на PerNight, като количеството се изчислява по формулата количеството = брой гости × количество.
Цени на нощувките – направихме малка промяна в обработката на цените. Вече се използват цените според данъчния модел в Clock. Използват се новите полета unitPriceAfterTax или unitPriceBeforeTax вместо unitPrice, както беше досега.
Брой гости – вече се използват полетата @adultCount и @childCount, като броят на гостите се разпределя по стаи.
Информация за плащанията – стойностите на атрибутите paidamount, dueAmountAtBooking и dueAmountOnArrival се добавят към забележката на резервацията, ако са налични.
Импорт на плащания – както и досега, стойността се извлича от psp възела.
Отстранени конфликти
Компании - Корпоративни гости – списъкът включваше профили, които вече са архивирани (след сливане на профили).
Характеристики на стаите – от списъка със стаи се скриваха тези, които имат статус OOS.
Лог на операциите (Лог на фискалните операции) – резултатите не се филтрираха коректно към зададена дата.
Интеграции
Feratel – Отстранен е проблем, при който натискането на бутона за експорт неколкократно в бърза последователност, можеше да доведе до дублирани експорти на профили на гости. Подобрихме механизма за експорт, за да предотвратим дублирани експорти.
RO e-Factura – Отстранен е проблем, засягащ някои акаунти, при който новосъздадени документи за електронни фактури не се поемаха от планирания процес за повторна обработка.
Private Analytics / BigQuery Export – Подобрен е процесът на експорт за по-добра обработка на промените в имената на абонаментите в Clock.
Счетоводни периоди – Като част от текущите ни счетоводни подобрения, въведохме Счетоводни периоди, позволяващи ви да конфигурирате GL кодове и центрове на разходи за различните потоци от данни в Clock.
GL кодовете за плащания, конфигурирани преди в GL Кодове, са преместени в новата секция „Счетоводни периоди“.
Можете да актуализирате кодовете в рамките на съществуващ период или да създадете нов период, за да запазите хронологичната счетоводна информация.
Пример: Ако GL кодът за плащания в брой се промени от 1111 на 1112 на 1 декември, просто създайте нов Счетоводен период, влизащ в сила от тази дата, и конфигурирайте новия набор от кодове. Справките за дати преди 1 декември ще продължат да показват 1111, докато справките от 1 декември нататък ще използват 1112.
- Това осигурява последователност и точност на историческите справки при промяна на счетоводните конфигурации във времето.