Онлайн эквайринг: реализован вывод деталей платежа при оплате через онлайн-эквайринг
https://youtrack.quirco.com/issue/Libra-13015
Вывод информации о деталях платежа реализован в комментарий к транзакции при оплате через онлайн-эквайринг
Уведомления: добавлена возможность отправки копии уведомления на адрес отеля
https://youtrack.quirco.com/issue/Libra-13510В модуль уведомлений (Notifications) добавлена настройка:
<Notifications Enabled="False" EmailEnabled="True" SmsEnabled="True">
<!-- Адрес, на который будут дублироваться email-сообщения, рассылаемые гостям -->
<SendEmailCopyTo></SendEmailCopyTo>В поле SendEmailCopyTo можно указать адрес, на который будет оправляться копия письма гостя (адрес будет фигурировать в BCC и не будет виден гостю).
Бронь: добавлен функционал ручного ввода номера комнаты
https://youtrack.quirco.com/issue/Libra-13369
Добавлен функционал ручного ввода номера комнаты при поселении или присвоении комнаты, чтоб не надо было проваливаться в список. По нажатию кнопки "Назначить комнаты" открывает окно назначения комнаты на бронь с возможностью выбора комнаты из выпадающего списка для каждой строки либо ручного ввода значения в ячейке:
Подробнее см.
RMC.Scala: передача сроков пребывания
https://youtrack.quirco.com/issue/Libra-13375
Теперь передаются параметры пребывания для всех иностранных граждан из полей "Срок пребывания", независимо от того, заполнены ли серия и номер миграционной карты:
Расчёт стоимости брони по старым параметрам календаря гостиницы, действующим на дату бронирования
https://youtrack.quirco.com/issue/Libra-11921
Объектам необходимо продлевать бронь, переселять бронь в другой тип комнаты без использвания галки "не пересчитывать стоимость" в рамках настроек того Сезона/Типа дня в "Календаре гостиницы" (Сегмента загрузки - просил отель, использующий модуль Управления доходами), в котором была данная бронь создана. Даже если эти настройки изменились. То есть желателен функционал подобный параметру "Дата обменного курса" в счете Брони.
Реализация:
В мастере изменения брони на вкладку выбора типа номера, пакетов и тарифа, добавлено поле "Базовая дата расчёта цен", которое заполняется по-умолчанию датой создания брони. При внесении изменений в брони система использует эту дату для вычисления сезона, типа дня и сегмента загрузки, действующих в указанный момент времени. Если необходимо пересчитать стоимость по текущим условиям, значения в этом поле можно сбросить (очистить).
Динамические тарифы, управление доходами: добавлен экран отображения в виде календаря
https://youtrack.quirco.com/issue/Libra-12904
Так как при работе с несколькими группами управления доходами после сохранения действий экран сбрасывался и возвращался к первой группе управления доходами в самое начало списка и на экране отображалось небольшое количество записей, можно теперь отобразить календарный режим с возможностью выбора группы управления во вкладке:
Логус vs Битрикс24 через виджет: передавать ответственного (менеджера) в обе стороны.
https://youtrack.quirco.com/issue/Libra-13337
Из Логуса \ карточка брони \ Прочая информация \ Менеджер передавать данные в поле "Ответственный" карточки сделки в Битрикс24.
Если изменение происходит в одном из полей, они передаются в другое.
Финансовые документы: Отображать баланс строгого фин.дока (Чека)
https://youtrack.quirco.com/issue/Libra-8424
На профиле компании множество фин.доков, объединяющих,где
сотни транзакций безнала объединены с банковскими выписками ( 150 код и код БАНК )
Баланс компании не равен нулю. Бухгалтер не понимает, какие брони не оплачены или оплачены частично. См. скрин 2.
Задача 2:
Аналогично на примере Будапешта.
В счете имеется несколько фин.доков. В результате оплаты валютных транзакций локальной валютой,
возникла ненулевая сумма транзакций фин.дока в локальной валюте.
Хорошо бы видеть, что именно этот фин.док надо доплатить.
Задача 3:
Представим, что на счете брони много транзакций.
аналогично по ФЗ-54 когда в счете много фин.доков, желательно видеть, какие надо "закрыть"
а не открывать все последовательно и пересчитывать с калькулятором.
Задача 4:
Возврат по ФЗ-54 после формирования фин.дока. Желательно видеть, что в документе скорректированы транзакции, которые были оплачены.
и т.д.
Ожидаемый результат
Добавить обозначение "Начислений:" (Postings -англ) для доходных транзакций
Добавить показатель текущей суммы транзакций фин.дока как "К оплате" (Balance)
Печатные формы групповой брони. Добавить переменную для вывода ФИО менеджера
https://youtrack.quirco.com/issue/Libra-13271
Необходимо добавить переменную для вывода ФИО менеджера с вкладки "Общая информация группы", раздел "Прочая информация" для использования в печатных формах.
UPD
Также для реализации https://youtrack.quirco.com/issue/LS-4695 нужна переменная для вывода менеджера для обычных (не групповых) броней.
Bnovo. Вместо `ota_booking_id` в поле Код CRS записывается внутренний номер брони `number `.
https://youtrack.quirco.com/issue/Libra-13452
Задча
Сложилась непростая ситуация по двум объектам: Отельеры в уведомлении о новом бронировании получают ID бронирования, который задает сам источник бронирования - канал продаж (OTA), далее по этому ID они хотят найти бронирование в вашей PMS, но, к сожалению, там они его найти не могут, так как вместо ota_booking_id в поле Код CRS записывается внутренний номер брони Bnovo number.
В ответе на запрос бронирований (GET /bookings) :
{ "account_id":1111,
"ota_id":"bronevik",
"ota_booking_id":"1111",
"link_id":"0",
"status_id":1,
"roomtype_id":1113,
"plan_id":1112,
"parent_room_type_id":0,
"number":"3TTWA_270323" ....}Решение.
сохранять "number" в Logus в качестве внешнего идентификатора типа external_id (Поправить логику работы интерфейса на работу с этим полем)
а в поле "Код CRS" сохранять ota_booking_id
TL. Автоматическое осуществление возвратов по эквайрингу Сбер (эквайринг отеля)
https://youtrack.quirco.com/issue/Libra-13432
Задача
В общем случае есть два варианта отменить бронь, поступивную от ТЛ с депозитом:
- пользователь сам отменяет в ЛК
- отель отменяет по запросу пользователя в своем экстранете
В обоих случаях бронирование в Logus приходится отменять руками, так как бронирование с балансом. В этом случае пользователь Logus заходит и корректирует транзакцию оплаты в счете брони.
Запрос объекта в том, чтоб в этот момент происходил автотматический возврат денег на карту.
Сейчас они составляют реестр этих возвратов, пишут служебную записку бухгалтеру, она садится и проводит возвраты в ЛК СБер на основании служебки. Такая схема объект не устраивает.
Необходимо, чтоб Logus осуществлял также возврат по скорректированным транзакциям, полученным через Travelline
по аналогии с Libra-13317
Доработка
Требуется в заголовке запросов к TL указывать версию протокола 1.16, чтобы получать от них номер заказа Libra-13447
В гарантии оплаты добавилось поле PaymentTransactionId - Id транзакции в платежной системе. Заполняется только для эквайринга отеля.
<Comment Name="PaymentTransactionId">
<Text>389d532f-8d3d-7d71-a1a6-200302bbd499</Text>
</Comment> Требуется сохранять номер заказа при доставке брони в таблице CreditCardOperation
А дальше все, как тут: Libra-13317
Дополнительно
Реализовать возможность отключать автоматический возврат
Например, через параметр перечисления кодов транзакций, по которым его необходимо проводить, в настройках модуля экваринга:
<RefundCorrectedTransactionCodes>ONLINE,ТЛАВАНС</RefundCorrectedTransactionCodes>
<OnlineAcquiring Enabled="True" Provider="Sberbank" CheckPaymentsCron="0 0/3 * * * ?" OrderTimeoutMinutes="15" OnlineUrl="booking"> <Sberbank> <!-- Для продакшен: https://securepayments.sberbank.ru/payment/rest --> <Url>https://3dsec.sberbank.ru/payment/rest</Url> <UserName>pms_libra-api</UserName> <Password>pms_libra</Password> <!-- Валюта, в которой выполняется оплата --> <Currency>RUB</Currency> <!-- Код валюты платежа ISO 4217. --> <CurrencyCode>643</CurrencyCode> <!-- Используется для товарной корзины --> <Mappings> <!-- Ставка НДС, доступны следующие значения: 0 – без НДС; 1 – НДС по ставке 0%; 2 – НДС чека по ставке 10%; 4 – НДС чека по расчетной ставке 10/110; 6 - НДС чека по ставке 20%; 7 - НДС чека по расчётной ставке 20/120. Тег кода налога должен начинаться с префикса 'T' --> <TaxDefinitionCode> <!--<TБЕЗНДС>0</TБЕЗНДС>--> <!--<TНДСВКЛ>6</TНДСВКЛ>--> </TaxDefinitionCode> </Mappings> </Sberbank>
Интеграция с телефонной станцией Alcatel
https://youtrack.quirco.com/issue/Libra-13332
"Прошу рассмотреть техническую возможность интеграции Logus и телефонной станции Alcatel. Необходимо реализовать стыковку для того что бы сотрудник hk мог набрать на телефоне в номере комбинацию цифр, после чего в программе Logus менялся статус уборки номера. Пересылаю документацию Alcatel. Просьба ответить по срокам реализации, вопрос важный и срочный, и озвучить стоимость."
Наше понимание:
Необходимо полностью перенести всю логику управления уборками из Avaya адаптировав только коды вызова под спецификацию Alcatel, а именно по автоматизации статусов:
- начала уборки
- перевод статуса номера с учетом занятости номера (обработка статуса визуального осмотра горничной)
- перевод статуса номера с учетом требования инспекции для уборки и т.д.
Результат
Разработан новый модуль.
В конфигурационный файл сервера добавлен блок настроек:
<!-- Телефония Alcatel OmniPCX 4400 (PABX) -->
<Alcatel Enabled="False">
<!-- IP адрес сервера PABX -->
<Server></Server>
<!-- Порт взаимодействия -->
<Port>2561</Port>
<!-- Тип уборки по умолчанию (используется при переводе в уборку из номера) -->
<CleaningTypeCode>DC</CleaningTypeCode>
<!-- Код объекта -->
<PropertyCode>MAIN</PropertyCode>
<!-- Длина блока GPIN. Возможны 2 варианта - 5 и 8 -->
<GpinLenght>8</GpinLenght>
</Alcatel>Для связи уборщицы с её профилем гостя необходимо завести допполе с кодом ALCATEL_ID по аналогии, как это работает в интеграции с AVAYA
Обрабатываемые статусы, которые набираются с телефона:
MaidArrivesInRoom = 0, RoomCleaned = 1, MustBeCleanedNewGuest = 2, MustBeCleanedSameGuest = 3, Ext4 = 4, RoomCleanNeedsInspection = 5, RoomCleanVacant = 6, RoomNotCleanVacant = 7, Ext8 = 8, Ext9 = 9
Разработка связки Logus с Premium Bonus
https://youtrack.quirco.com/issue/Libra-12632
Полное ТЗ - во вложении. Кратко - ниже.
- Номинал карты гостя присваивается в системе Premium Bonus (далее - РВ) автоматически.
- Уровни карт, накопление бонусов, уровни скидок – максимально всё настраивается в РВ.
Варианты: - Desktop (через администратора на стойке службы приёма и размещения).
1.1. Гость приезжает в отель для размещения без брони или по неоплаченной брони.
1.2. Администратор размещает гостя и в процессе поселения просит предъявить некий идентификатор (в виде номера телефона, номера карты, кода приложения).
1.3. При сохранении поселения Logus проверяет запросом buyer-info наличие пользователя в РВ и в случае отсутствия отправляет все имеющиеся данные о госте (ФИО, пол, дату рождения и e-mail) запросом на регистрацию buyer-register в РВ (также рекомендуется верифицировать номер телефона гостя запросами send-register-code и verify-confirmation-code).
1.4. После предъявления идентификатора гостю приходит СМС с кодом подтверждения (у отеля должен быть договор с смс-центром).
1.5. Если гость найден, производится анализ возможных скидок и сумм баллов для списания, возможная скидка: Logus направляет в запросе к РВ номер телефона гостя и состав заказа, а в ответ получает информацию о доступной выгоде, которая должна вывестись на экране оператору для трансляции информации гостю.
1.6. В следующее окно администратор вписывает сумму списываемых баллов (например, всего 1000 баллов, доступно для списания 700, гость хочет списать 500). Сумма передаётся в PB: общее количество доступных баллов снижается, в Logus оплата "живыми" деньгами происходит на сумму, уменьшенную на сумму баллов. - Сайт отеля (бронирование номера с предоплатой через сайт отеля).
2.1. Гость бронирует номер на сайте отеля, в обязательном порядке указывая номер своего мобильного телефона.
2.1.1 Гость сохраняет броню, в РВ передаётся запрос и производится проверка бонусного счёта, предлагается использование баллов при расчёте. Гость оплачивает броню.
2.1.2 Гость сохраняет броню, в РВ передаётся запрос и производится проверка бонусного счёта, предлагается использование баллов при расчёте. Гость не оплачивает броню, учитывая имеющиеся бонусы для оплаты на месте. - При отказе от брони в РВ направляется соответствующий запрос на отмену покупки, после чего производится возврат бонусов.
Начисление таранзакций прошлым числом: добавить управление поведением в файл конфигурации
https://youtrack.quirco.com/issue/Libra-7837
В настройках должен быть добавлен флаг AllowPostWithPastDate, установка которого определяет поведение выгрузок за прошлые числа
TL2: обработка ID профиля гостя из внешней системы TL
https://youtrack.quirco.com/issue/Libra-9518
Добавить ключ в настройки модуля TL2
<CreateGuestProfiles>True</CreateGuestProfiles>При доставке броней и модификаций производить поиск профиля гостя по ID = GenericNo и привязывать.
Если профиль не найден, то создавать
<ResGuest ResGuestRPH="2">
<Profiles>
<ProfileInfo>
<UniqueID Type="21" ID_Context="PMS" ID="4323223" />
<Profile>
<Customer BirthDate="1998-12-31" Gender="Male">
<Document DocType="ПАСГРАРФ" DocID="3403 092***"/>
<PersonName>
<GivenName>Иван</GivenName>
<MiddleName>Николаевич</MiddleName>
<Surname>ФамилияВторая</Surname>
</PersonName>
<Telephone PhoneNumber="73432432425"/>
<Email>fiwev107811@wwrmails.com</Email>
<CitizenCountryName Code="RUS"/>
</Customer>
</Profile>
</ProfileInfo>
</Profiles>
</ResGuest>UPD. Важно смотреть на ID_Context="PMS"
В дальнейшем для ID_Context="TL" планируется другая логика. Поиск по доп.полю на профиле. Или создание отдельного поля в профиле гостя с внешним идентификатором.
WEB API: Доработать возможность изменения ExternalId брони через API
https://youtrack.quirco.com/issue/Libra-12880
Цель клиента: в связи с основной проблемой клиента - нужно , чтобы после заезда интеграция не трогала тариф и пакеты после заезда гостя.
Необходим метод API, который будет обновлять ExternalId брони через API.
Примечание:
По их бизнес-процессу с продлением проживания по другому тарифу/другой скидке и наш новый виджет не поможет. Они сейчас в таких бронях руками зануляют внешний айди, чтобы интеграция не ломала бронь, а по выезду назад вписывают айди
Результат выполнения
Обновить ExternalId можно, сделав запрос:POST /api/Reservation/{genericNo}
json
{"SetExternalIdRequest": {"SystemId": "string","Value": "string","Url": "string"}}Терминалы кредитных карт: поддержка нескольких терминалов разных юр.лиц на одной рабочей станции
- https://youtrack.quirco.com/issue/Libra-11903
Это необходимо для реализации оплат через разные терминалы одного банка или разные терминалы разных банков.
Для реализации используется поддержка удаленного подключения к терминалу https://docs.logus.pro/pages/viewpage.action?pageId=56395693
Для терминалов Сбера работает опция https://youtrack.quirco.com/issue/Libra-4292
Сейчас Код оплаты можно жёстко привязать к терминалу определённого типа. Такой вид оплаты будет доступен только на рабочих станциях, где настроен интерфейс с этим терминалом. Для этого во вкладке "Фискализация и эквайринг" добавлено поле "Интерфейс кредитного терминала", которое определяет требования к конкретному фискальному интерфейсу:
Если данное поле оставить пустым, для оплаты будет выбран первый доступный кредитный терминал на рабочей станции (как это и работало ранее).
Но это не решает проблемы выбора терминала для разных юр.лиц объекта в общем случае. Например, при использовании налоговых схем.
Необходима привязка терминала к юр.лицу объекта для каждой рабочей станции по аналогии с выбором фискала для фискализации.
Добавить в справочнике сегментов таблицу диапазонов загрузки отдельно для каждой категории управления доходами
https://youtrack.quirco.com/issue/Libra-12414
Задача клиента:
Управление доходами
У отеля используются разные диапазоны загрузки для разных групп управления доходами (категорий номеров)
Предлагаемая доработка:
Добавить в справочнике сегментов таблицу диапазонов загрузки отдельно для каждой категории управления доходами
В остальном все без изменений.
Сегмент подбирается согласно установленной группе доходов. Если такого сегмента не найдено, подбирается сегмент с пустой группой доходов.
Услуги. Массовое начисление. Добавить поля
https://youtrack.quirco.com/issue/Libra-12766
В имеющийся функционал массового начисления, добавить:
- комментарий (см. скрин ниже)
- плановую дату "Запланировать начисление" (см. скрин ниже)
Стольбцы: - группа услуг (применена группировка)
- код транзакции (скрыт по умолчанию)
- код услуги (скрыт по умолчанию)
- комментарий (скрыт по умолчанию) - с варианта услуги
Результат
Возможность сохранения номеров для бронирования только отелем
https://youtrack.quirco.com/issue/Libra-11751
В настройках канала бронирования добавляется возможность указать минимальное кол-во свободных номеров на объекте, после которого продажа через канал встанет на стоп. Количество регулируется по каждому типу номера в отдельности.Здравствуйте. Уже не раз сталкивались с тем что не успеваем бронировать последние номера в категории, они занимаются бронями из портала бронирования, во избежание таких ситуаций просим настроить квоты, чтобы последние три номера в категории были недоступны для продажи через портал бронирования, а только через Логус. В Трэвеллайне мы так настроили, а в портале можете сделать только вы.
Тарифы: изменить алгоритм расчета цен для броней с разделением
https://youtrack.quirco.com/issue/Libra-10238
Текущее поведение системы приносит некоторые неудобства по той причине, что общая стоимость гостей в разделении подгоняется под прайсовую стоимость в Логусе. А прайсовая сумма задаётся за всех гостей в совокупности - например за всех трёх гостей, а не за одного гостя при трёхместном размещении. Такое поведение привозит к операции деления стоимости и погрешностям из-за округления. Погрешность автоматически корректируется Логусом для того, чтобы сумма по всем гостям совпала с прайсовой. В результате цена проживания последнего гостя может отличаться от остальных.
Для того, чтобы избежать такой картины, в настройки объекта в секцию разделения счетов добавляется параметр "исправлять ошибки округления" (по-умолчанию он ВЫКЛЮЧЕН, т.е. "подгонка" цены осуществляться не будет).
Бронь: аудит внесения изменений в карточку брони
https://youtrack.quirco.com/issue/Libra-11985
Общая схема работы аудитора с бронями:
- Аудитор проверяет каждую созданную броню на корректность и полноту внесённой информации.
- Если все данные в брони корректны, аудитор ставит флаг «Проверено» в карточке брони.
- Если в дальнейшем в броню были внесены какие-либо изменения, при сохранении этих изменений флаг «Проверено» автоматически снимается.
- По спискам броней и групп аудитор ориентируется, какие брони требуют проверки.
- Право установки флага есть только у аудитора.
Модуль аудита следит за внесением изменений в брони и устанавливает тег "проверить" тем броням, в которые были внесены изменения.
Изменение брони - это любое изменение, которое либо повлекло изменение стоимости брони (оплаты не учитываются), либо повлекло изменение тарифа, типа комнаты или комнаты.
Список броней: отображать наличие невыполненных задач
https://youtrack.quirco.com/issue/Libra-12205
Если у брони есть задачи в активном статусе (подтверждена или в процессе), то в списке напротив такой брони отображается красный флажок
Бронь: при создании брони предупреждать, если на весь непрерывный интервал проживания нет свободной комнаты (и в процессе проживания понадобится переселение)
https://youtrack.quirco.com/issue/Libra-3857
А также дополнительно на бронь вешать тег "ПЕРЕСЕЛ". (Тег создавать автоматически)
Лимиты карманов: добавить возможность делать общий лимит на несколько карманов
https://youtrack.quirco.com/issue/Libra-11790
В настройках лимитов карманов счёта добавляется параметр "группа лимита" (из выпадающего списка со значениями ABCDEF).
У каждого кармана можно указать группу лимита, или оставить её пустой.
Для карманов, у которых задана одинаковая непустая группа лимитов, сумма лимитов объединяется и проверки осуществляются сразу по всей группе карманов.
Бронь: добавить ссылки на онлайн-документы в карточку брони
https://youtrack.quirco.com/issue/Libra-9650
На карточке брони отображается список документов, доступных для формирования онлайн. По клику на документ ссылка на него копируется в буфер обмена.
Чтобы функция работала, необходимо в настройках объекта прописать "Адрес веб-сервера Logus".
Джобы Логус: не запускать отправку отчётов на старте службы
https://youtrack.quirco.com/issue/Libra-13456
Если кому-то нужно будет запустить отправку отчётов вручную - это можно сделать через панель обновления джобов
Импорт банковской выписки: возможность загружать возвраты средств или агентские выплаты
https://youtrack.quirco.com/issue/Libra-9025
В функционал импорта банковской выписки добавить признак "загружать возвраты" - при установленном признаке исходящие от отеля оплаты должны трактоваться как входящие с противоположным знаком, но назначение платежа в таких строках распознавать не нужно (т.е. разносить на бронь такие оплаты не нужно).
#### Цель клиента:
Через банковскую выписку заносить в Логус возвраты выполненные через банк клиент.
Это необходимо для случаев когда возврат выполняется через банк клиент или при выплате агентской комиссии
**Пример:**
Гость заплатил через банк полную сумму за весь срок проживания, прожил не все запланированные дни и на момент выезда у него осталась часть средств, их перенесли на профиль гостя и выселили бронь. А уже потом через бухов выполнили возврат через банк клиент. А на счете профиля гостя осталась пере плата, который необходимо вручную приравнять к нулю после фактического возврата. В файле банковской этот возраст есть. пример файла в вложении.
#### Ожидаемый результат:
Через банковскую выписку заносить в Логус возвраты выполненные через банк клиент.
Клиент просит оценить стоимость доработки.
Валютные брони: при редактировании стоимости в валюте, отличной от валюты таймлайна, осуществлять пересчёт между валютами по обратному курсу
https://youtrack.quirco.com/issue/Libra-10107
На примере задачи - есть валютная бронь, стоимость которой зафиксирована в долларах, а локальная валюта объекта - росс. рубли.
Если осуществляется редактирование стоимости в локальной валюте, стоимость в долларах должна пересчитаться по курсу из рублей в доллары по дате согласно настройкам объекта.
Тарифы: изменить алгоритм расчета цен для броней с разделением.
https://youtrack.quirco.com/issue/Libra-10238
Текущее поведение системы приносит некоторые неудобства по той причине, что общая стоимость гостей в разделении подгоняется под прайсовую стоимость в Логусе. А прайсовая сумма задаётся за всех гостей в совокупности - например за всех трёх гостей, а не за одного гостя при трёхместном размещении. Такое поведение привозит к операции деления стоимости и погрешностям из-за округления. Погрешность автоматически корректируется Логусом для того, чтобы сумма по всем гостям совпала с прайсовой. В результате цена проживания последнего гостя может отличаться от остальных.
Для того, чтобы избежать такой картины, в настройки объекта в секцию разделения счетов добавляется параметр "исправлять ошибки округления" (по-умолчанию он ВЫКЛЮЧЕН, т.е. "подгонка" цены осуществляться не будет).


