СПОСОБ, СИСТЕМА И МАШИНОЧИТАЕМЫЙ НОСИТЕЛЬ ДЛЯ АВТОМАТИЗИРОВАННОЙ ОБРАБОТКИ ИНФОРМАЦИИ ПРИ БРОНИРОВАНИИ ПОЕЗДОК
METHOD, SYSTEM, AND MACHINE-READABLE CARRIER FOR AUTOMATED INFORMATION PROCESSING, WHEN BOOKING TRIPS

ОБЛАСТЬ ТЕХНИКИ
Настоящее техническое решение относится к области вычислительной техники, в частности к автоматизации и обработке информации в области бизнес-туризма и оформлению командировок внутри организации.
УРОВЕНЬ ТЕХНИКИ
Из уровня техники известен источник информации RU 2017 109 561 A, опубликованный 25.09.2018 г., раскрывающий способ формирования плана путешествий с помощью электронного устройства пользователя, который позволяет на основе множества критериев осуществить автоматический расчет и подбор наиболее оптимального плана путешествия между множеством точек маршрута, определить наиболее подходящий тип перемещения между точками маршрута, осуществить необходимые процедуры бронирования мест проживания и посещения мест интереса.
Из уровня техники также известен источник информации EP 3510534 А1, опубликованный 17.07.2019 г., раскрывающий систему управления расходами. Устройство управления расходами, сконфигурировано для приема от клиентского устройства по меньшей мере одного параметра, связанного с событием поездки, создания по меньшей мере одного запроса на основе по меньшей мере одного параметра, передачи по меньшей мере одного запроса в базу данных, приема из базы данных ответных данных, отвечающих по меньшей мере на один запрос, создания теста, включающего в себя бюджет поездки, используя механизм обработки, связанный по меньшей мере с одним параметром. Созданный тест передают на клиентское устройство.
Предлагаемое решение отличается от известных из уровня техники решений тем, что осуществляют интеллектуальный подбор элементов маршрута поездки, на котором осуществляют фильтрацию данных поставщиков услуг, по созданному словарю ключевых слов, используемых в описании тарифов. Отличием от известно уровня техники является также то, что посредством алгоритмов кластеризации анализируют историю бронирования пользователя и историю бронирования других пользователей, с похожими элементами маршрута поездки для предоставления наилучших предложений поездки для пользователя с учетом тревел-политики, а также то, что по завершении поездки, в автоматическом режиме, направляют отчетные документы в блок отчетности, на основе меток, присвоенных забронированной поездке и\или пользователю, для формирования закрывающих документов по поездке, причем отчетность формируется на основе конструктора, настраиваемого под конкретного пользователя.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
Технической задачей, на решение которой направлено заявленное техническое решение, является автоматизация внешних и внутренних операций при корпоративном бронировании поездок, выбор наилучших предложений поездки, за счет уникальных алгоритмов анализа клиентского запроса, а также персонализация предложений поездки под нужны организации и конкретных сотрудников. В связи с этим предложены способ, система и машиночитаемый носитель данных для автоматизированной обработки информации при бронировании поездок, которые охарактеризованы в независимых пунктах формулы. Дополнительные варианты реализации настоящего изобретения представлены в зависимых пунктах изобретения.
Технический результат заключается в автоматизированной обработке информации при бронировании поездок, повышении быстродействия системы бронирования поездки, за счет автоматизированной обработки информации и уникальных алгоритмов подбора предложений поездки. Дополнительно, технический результат заключается в реализации назначения.
Заявленный результат достигается за счет осуществления  компьютерно-реализуемого способа автоматизированной обработки информации при бронировании поездок, содержащего сервер и терминал пользователя, где сервер включает процессор и память, хранящую инструкции, исполняемые процессором, и включающего следующие этапы, на которых:
на терминале пользователя вводят информацию, необходимую для бронирования поездки, и передают введенную информацию на сервер;
на сервере осуществляют интеллектуальный подбор элементов маршрута поездки посредством блока интеллектуального подбора предложений, где осуществляют обработку полученной информации, посредством фильтрации данных поставщиков услуг, по созданному словарю ключевых слов, используемых в описании тарифов;
посредством алгоритмов кластеризации, в блоке интеллектуального подбора предложений, анализируют историю бронирования пользователя и историю бронирования других пользователей, с похожими элементами маршрута поездки для определения критериев формирования элементов маршрута поездки, если по по меньшей мере одному показателю анализа  у пользователя, осуществляющего бронирование, достигнут заранее заданный уровень, то выделяют данный показатель и автоматически включают его в тревел-политику пользователя, которая используется для предоставления элементов маршрута;
на основе полученных данных, предоставляют пользователю по меньшей мере два предложения поездок посредством терминала, и пользователь выбирает актуальное для себя предложение поездки;
на основе предложенной поездки, сервер автоматически предоставляет пользователю дополнительные элементы маршрута;
отправляют выбранное пользователем предложение поездки на согласование через блок автоматизации организационных структур, причем на время согласования выбранные элементы маршрута резервируются до момента бронирования;
после согласования предложения поездки осуществляют бронирование ранее зарезервированных элементов маршрута посредством блока бронирования и присваивают метку бронированию и\или пользователю;
дальнейшее сопровождение забронированного предложения поездки, связанного с изменением элементов маршрута или уточнением элементов маршрута или оповещением, касательно элементов маршрута, осуществляют посредством чат-бота через блок поддержки вторичных операций;
по завершении поездки, в автоматическом режиме, направляют отчетные документы в блок отчетности, на основе меток, присвоенных забронированной поездке и\или пользователю, для формирования закрывающих документов по поездке, причем отчетность формируется на основе конструктора, настраиваемого под конкретного пользователя.
В частном варианте реализации предлагаемого способа, анализ осуществляется по информации о цене, тарифах/категории номеров/классов обслуживания, наиболее встречающихся маршрутов, наличии вторичных операций возврата и обмена элементов маршрута, НДС, продолжительности маршрута.
В другом частном варианте реализации предлагаемого способа, дополнительно дальнейшее сопровождение забронированного предложения поездки, связанного с изменением элементов маршрута или уточнением элементов маршрута или оповещением, осуществляется посредством голосового помощника.
В другом частном варианте реализации предлагаемого способа, этап персонализации осуществляется на уровне конкретного пользователя и/или на уровне аккаунта пользователя и/или на уровне всей отрасли.
В другом частном варианте реализации предлагаемого способа, если этап персонализации осуществляется на уровне аккаунта пользователя, то выделяют предложения, которые соответствуют тревел-политики компании.
В другом частном варианте реализации предлагаемого способа, на этапе персонализации, при выделении предложений для командировок осуществляют ранжирование на основе отзывов по элементам маршрута.
В другом частном варианте реализации предлагаемого способа, дополнительными элементами маршрута являются по меньшей мере отель, билет на поезд, билет на самолет, трансфер, информация о необходимости визы и форма для ее получения.
В другом частном варианте реализации предлагаемого способа, дополнительно данные о поездке направляют в блок аналитики, для агрегирования данных, с целью принятия стратегических решений, оптимизации работы по планированию и организации поездок.
Заявленный результат также достигается за счет работы системы для автоматизированной обработки информации при бронировании поездок, которая содержит:
вычислительное устройство, выполненное с возможностью осуществления компьютерно-реализуемого способа,
блок интеллектуального подбора предложений;
блок поддержки вторичных операций;
блок бронирования;
блок автоматизации организационных структур;
блок отчетности, содержащий конструктор, формирующий отчетность для конкретного пользователя;
блок аналитики;
терминал пользователя.
Заявленный результат достигается также за счет работы машиночитаемого носителя информации, содержащий процессор и память, хранящую инструкции для выполнения процессором этапов компьютерно-реализуемого способа.
ОПИСАНИЕ ЧЕРТЕЖЕЙ
Реализация изобретения будет описана в дальнейшем в соответствии с прилагаемыми чертежами, которые представлены для пояснения сути изобретения и никоим образом не ограничивают область изобретения. К заявке прилагаются следующие чертежи:
Фиг. 1 иллюстрирует схему взаимодействия пользователя с предлагаемым решением.
Фиг. 2 иллюстрирует схему работы вычислительного устройства.
ДЕТАЛЬНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ
В приведенном ниже подробном описании реализации изобретения приведены многочисленные детали реализации, призванные обеспечить отчетливое понимание настоящего изобретения. Однако, квалифицированному в предметной области специалисту, будет очевидно каким образом можно использовать настоящее изобретение, как с данными деталями реализации, так и без них. В других случаях хорошо известные методы, процедуры и компоненты не были описаны подробно, чтобы не затруднять излишне понимание особенностей настоящего изобретения.
Кроме того, из приведенного изложения будет ясно, что изобретение не ограничивается приведенной реализацией. Многочисленные возможные модификации, изменения, вариации и замены, сохраняющие суть и форму настоящего изобретения, будут очевидными для квалифицированных в предметной области специалистов.
Предлагаемое решение включает способ, систему, реализующую способ, а также машиночитаемый носитель информации для автоматизированной обработки информации при бронировании поездок.
Система для автоматизированной обработки информации при бронировании поездок включает вычислительное устройство (сервер) (100), блок интеллектуального подбора предложений (101), блок автоматизации организационных структур (102), блок бронирования (103), блок поддержки вторичных операций (104), блок отчетности, содержащий конструктор, формирующий отчетность для конкретного пользователя (105), блок аналитики (106), а также терминал пользователя (110).
Терминал пользователя (110) может быть, но не ограничиваясь, персональным компьютером, мобильным устройством, планшетным компьютером.
Пользователь на терминале пользователя (110) вводит информацию необходимую для бронирования поездки.  Информация для бронирования поездки включает в себя по меньшей мере направление маршрута поездки, даты поездки, время отъезда и время приезда, наличие багажа, возможность возврата или обмена билета и т.д.
Посредством терминала пользователя, передают введенную информацию на сервер (100), где посредством блока интеллектуального подбора предложений (101), осуществляют обработку полученной информации, посредством фильтрации данных поставщиков услуг, по созданному словарю ключевых слов, используемых в описании тарифов.
Посредством алгоритмов кластеризации, в блоке интеллектуального подбора предложений (101), анализируют историю бронирования пользователя и историю бронирования других пользователей, с похожими элементами маршрута поездки для определения критериев формирования элементов маршрута поездки. Анализ осуществляется по информации о цене, тарифах/категории номеров/классов обслуживания, наиболее встречающихся маршрутов, наличии вторичных операций возврата и обмена элементов маршрута, НДС, продолжительности маршрута, если по по меньшей мере одному показателю анализа достигнут заранее заданный уровень, то выделяют данный показатель и автоматически включают его в тревел-политику пользователя, которая используется для предоставления элементов маршрута.
Под термином тревел-политика, в материалах настоящей заявки, подразумевается информация по предпочтению каждого пользователя, а также данные программ лояльности, особенности подготовки поездок в зависимости от страны, транспорта, любимых брендов товаров. Тревел-политика является настраиваемой, т.е. в нее могут добавляться новые данные о предпочтениях пользователя. Кроме того, поиск предложений поездки осуществляется на основе тревел-политики пользователя.
Например, если у одного из пользователей по определенному проценту авиабилетов встречается операция отмены со штрафом, то будет предложено создание тревел-политики, согласно которой этому пользователю будет разрешено покупать только возвратные авиабилеты, т.е. без дополнительных финансовых потерь. Также в качестве примера можно привести ситуацию, где для руководителей регулярно бронируется бизнес-класс или размещения класса люкс, и процент поездок с такими условиями превышает определенный уровень, то рейтинг таких тарифов будет повышаться и вытаскиваться на более высокую позицию в списке предложений для клиента, даже не смотря на более высокую стоимость и также будет включен в тревел-политику данного пользователя.
На основе полученных данных, предоставляют пользователю по меньшей мере два предложения поездок посредством терминала (110), и пользователь выбирает актуальное для себя предложение поездки.
В результате обработки данных, поступающих от большого количества разных поставщиков, отсекаются заведомо невыгодные и неудобные варианты элементов маршрута поездки. Предложение для пользователя формируется по лучшим сочетаниям таких важных факторов услуги, как цена, возвратность, длительность, возможность включения дополнительных услуг. В итоге, пользователю предлагается максимально возможный выбор элементов маршрута поездки, но проанализированный заранее, исходя из реальных потребностей отрасли бизнес-туризма. Например, если пользователю необходим билет Москва-Санкт-Петербург, то билеты с одной или несколькими пересадками убираются из выборки, так как расстояние между города не большое. Также, например, если пользователь не берет багаж, то варианты с багажом также убираются из выборки.
Использование словаря ключевых слов позволит мгновенно, без необходимости получения подтверждения от авиакомпании или гостиницы, предложить пользователю оптимальные варианты времени, даты вылета, аэропорта и гостиниц, что позволяет экономить до половины бюджета на перелетах/размещении.
Для создания словаря ключевых слов, используемых в описании тарифов (авиакомпаний, отлей) осуществляется разбор неструктурированного языка для формализации тарифных правил.
На каждый запрос, на поиск элементов маршрута, сохраняют всю служебную информацию из GDS (Global Distribution System) о запросе и выписанных билетах, что позволяет использовать эти данные для создания модели выделения структурных элементов в правилах тарифов, а также собирать статистическую информацию о наиболее популярных элементах маршрута, для последующего анализа.
В качестве примера, распишем построение модели выделения структурных элементов в правилах тарифов авиакомпаний (Аэрофлот и S7). Был выделен набор слабоструктурированных текстовых данных на естественном языке (около 10 ГБ), полученные данные были разбиты в соотношении 70% / 30%, где 70% использовались для обучения, а 30% оставили для тестирования реализованной группы алгоритмов. Из 70% были выделены все возможные варианты атрибутов тарифов и их значения.
Первым этапом является построение математической модели вида и значения атрибута (элемента тарифа и его значения). Для этого проводилось тематическое моделирование на основе метода латентного размещения Дирихле (latent Dirichlet allocation, LDA). Для обучения модели использовался EM-алгоритм (Jiangtao Yin; Yanfeng Zhang; Lixin Gao (2012). "Accelerating Expectation-Maximization Algorithms with Frequent Updates"). Проверка на тестовой выборке дала результат 95%, чего достаточно, чтобы с большой долей вероятности сказать, что алгоритм работает верно.
Далее, после определения атрибута тарифа, необходимо было распознать его дополнительное значение, т.е. получить дополнительные факты из строки, такие как размер доступного багажа, ручной клади и т.д.. Для этого был реализован GLR-парсер (Generalized Left-to-right Rightmost derivation parser), основанный на одноименном алгоритме, который обеспечивает наибольшую скорость работы по сравнению с другими алгоритмами данного класса.
Для функционирования GLR алгоритма, на основе обучающей выборки, был составлен словарь ключевых слов, используемых в описании тарифов и контекстно-свободная грамматика, описывающая синтаксическую структуру выделяемых цепочек. Например, но не ограничиваясь, выделяются главные характеристики, которые повторяются несколько раз в массиве поставщиков, а именно: возвратность, возможность обмена, наличие багажа, НДС, формат кровати.
Также данная модель выделения структурных элементов из неструктурированных данных используется для обработки информации, полученной от GDS, касающаяся сообщений, непрерывно поступающих от авиакомпаний о переносах, изменениях, вводах новых тарифов, начале посадки на рейс и прочей служебной информации для информирования и уведомления пользователей об изменениях в ранее сделанных бронированиях авиабилетов.
Как было описано выше, блок интеллектуального подбора предложений (101) анализирует большие данные и осуществляет их кластеризацию для определения критериев формирования элементов маршрута поездки (персонализация элементов маршрута для организации и/или для конкретного пользователя).
На основе истории бронирований пользователей, их данных (пола, возраста, бюджета и других параметров), и опыта пользователей с аналогичным профилем, а также всей отрасли в целом, можно с высокой долей вероятности предложить путешественнику наиболее подходящий ему вариант.
Этап персонализации осуществляется на уровне конкретного пользователя и/или на уровне аккаунта пользователя и/или на уровне всей отрасли.
Посредством алгоритмов кластеризации, анализируют историю бронирований пользователя, а также историю бронирований пользователей, с похожими элементами маршрута (на уровне одного аккаунта и отрасли в целом) для отбора наиболее эффективных элементов маршрута. Анализ осуществляется от всей отрасли до пользователя, т.е. неэффективные элементы маршрута могут быть отсечены уже на уровне всей отрасли (например, билет с пересадкой), затем из оставшихся вариантов анализируют на уровне одного аккаунта (например, билеты без возможности возврата) и в конечном счете из оставшихся анализируют на уровне пользователя, который совершает поездку (например, билеты с багажом, так как пользователь обычно ездит без багажа, только с ручной кладью). Данный анализ может производиться как в совокупности, по всем уровням, там и по каждому уровню отдельно.
В итоге, пользователю предлагают выбрать из 2-3х вариантов, а не из десятков предложений. Например, сотрудник несколько раз выбирает услуги одной авиакомпании для накопления бонусов по личной карте. Система отслеживает подобные случаи и с большей долей вероятности будет чаще предлагать услуги именно этого перевозчика при прочих равных условиях.
Для реализации данной задачи были собраны большие массивы данных с технической информацией (рейсы, даты, время, цена, тарифы) по поискам и бронированиям пользователей в виде, пригодном для дальнейшего исследований и нахождения зависимостей. На каждый поиск и бронирование, совершенные с помощью предлагаемого решения, сохраняется массив данных со всеми предложениями, которые были в момент поиска, анализ и кластеризация которых могут использоваться как для предсказания и выбора оптимального варианта для следующих командировок, так и для создания глубоких аналитических отчетов.
В качестве хранилища этих данных используется Apache Cassandra — распределённая система управления базами данных, относящаяся к классу NoSQL-систем колоночного типа и рассчитанная на создание высоко масштабируемых и надежных хранилищ больших массивов данных. Основным свойством данного типа баз данных является быстрая вставка данных, поэтому было принято решение об их использовании в системах сбора и логирования информации. Также Apache Cassandra относится к категории отказоустойчивых СУБД: данные автоматически реплицируются на несколько узлов распределенной сети, что позволяет при увеличении нагрузок и объемов данных масштабировать функциональные решения, работающие с данной СУБД.
В качестве инструмента обработки неструктурированных и слабоструктурированных данных используется Hadoop-кластер, построенный на программном каркасе Apache Spark. В отличие от классического обработчика из ядра Hadoop, реализующего двухуровневую концепцию MapReduce с дисковым хранилищем, решение Apache Spark использует специализированные примитивы для рекуррентной обработки в оперативной памяти, что дает значительный выигрыш в скорости работы. Это позволяет строить для пользователей любые аналитические отчеты с учетом снимка предложений в момент поиска.
Для персонализации данных был выбран подход с заданными “портретами” аудиторий. На основе анализа нескольких запросов и результирующих бронирований под каждого сотрудника, используя метод RBFNN (радиально базисных нейронных сетей), посредством которого определяется к какому кластеру с высокой долей вероятности принадлежит данный сотрудник и каков его “портрет”. С доверительной вероятностью 95% можно утверждать, что максимальное число бронирований для полной идентификации будет равно 5, то есть уже с 6-го бронирования для каждого сотрудника можно достаточно точно предугадывать оптимальный вариант в рамках тревел-бюджета.
При выборе наиболее подходящих элементов маршрута система обращает внимание на такие аспекты, как частые возвраты и изменения уже забронированных поездок. В таких случаях алгоритм выведет выше предложения с возвратными тарифами, т.е. которые можно вернуть или обменять без финансовых потерь, что позволит избежать затрат времени и денег в будущем.
Кроме того, алгоритм анализирует отзывы, отслеживает те услуги, которые проверены и одобрены путешественниками именно в разрезе командировок, а не обычных поездок.
После выбора предложения поездки, на основе предложенной поездки, сервер (100) автоматически предоставляет пользователю дополнительные элементы маршрута. Например, если клиент позаботился о перелете туда и обратно, то система предложит подобрать гостиницу в пункте назначения, если ее еще нет. Или если одним из пунктов назначения/отправления/пересадки является Москва, то клиенту будет предложено добавить билет на Аэроэкспресс автоматически именно в тот аэропорт, который задействован в поездке. А также автоматически предоставляется информация о необходимых визах и заполняются формы для их получения.
Результатом правильно построенной кластеризации получается решение, которое, имея на входе данные пользователя, направление и тревел-политику, с высокой долей достоверности подбирает оптимальный вариант, который удовлетворяет требованиям путешественника и при этом укладывается в тревел-бюджет.
Далее отправляют выбранное пользователем предложение поездки на согласование через блок автоматизации организационных структур (102), причем на время согласования выбранные элементы маршрута резервируются («замораживаются») до момента бронирования.
Для того, чтобы согласование предложенной поездки прошло быстро осуществляют структурирование сотрудников и поездок.
Помимо таких характеристик, как ФИО и документы, которые однозначно идентифицируют сотрудника организации, предлагаемое решение позволяет использовать в работе такой распространенный в кадровом учете идентификатор, как табельный номер. Это уникальный номер, который может использоваться в нескольких учетных системах клиента и тем самым, позволяет связать сущности каждого сотрудника и не прибегать к дополнительной идентификации.
Также осуществляют группировку сотрудников по отделам. Отделов можно создавать неограниченное количество, без каких-то специфичных требований по наименованию, что позволяет создавать структуры в зависимости от потребностей организации и делению сотрудников относительно потребности в командировках. Предлагаемое решение также позволяет настроить так называемое разделение видимости по отделам. Если есть такая потребность, данные по сотрудникам и их командировкам могут быть скрыты от сотрудников других отделов.
В рамках одного аккаунта можно настроить работу и нескольких организаций, с разными бюджетами, разными расчетными счетами и другими реквизитами. Это удобно, когда работа построена таким образом, что несмотря на разделение, нужны общие точки соприкосновения, например, общее ответственное лицо, общий контроль расходов и т.д.
Помимо классической вертикальной иерархической структуры нашим сервисом предусмотрены и возможности горизонтального деления и разграничения сотрудников, и поездок. Например, такой инструмент, как аналитики поездок. Частный случай такой аналитики – это Центры затрат (пример пользовательской аналитики). Центр затрат устанавливается на поездки целиком и на отдельные услуги, может быть, как обязательной характеристикой, так и нет, может устанавливаться заранее, а может вводиться каждый раз новый любым сотрудником организации. Таким образом, аналитики – очень гибкий настраиваемый инструмент, позволяющий структурировать и сортировать поездки в организации вне зависимости от его иерархической структуры.
Еще одним инструментом для классификации поездок являются Метки. Метки, в отличие от Аналитик могут быть присвоены еще и сотрудникам. Так что любая услуга, приобретенная на такого сотрудника, будет также помечена соответствующим образом. Метки тянутся в ряд отчетов, так что также могут служить для поиска и идентификации командировки.
Далее осуществляют автоматическое согласование предложенной поездки. Автоматизация процесса избавляет участников процесса от необходимости держать детали в голове, следовательно, снижает человеческий фактор и вероятность ошибок. Предлагаемое решение включает несколько вариантов автоматического согласования, а именно: согласование, схемы согласования и тревел-политики.
Согласование. Данный вариант подходит компаниям, где принятие решения о возможности покупки той или иной услуги находится в компетенции конкретного ответственного сотрудника/сотрудников, аспекты допустимости находятся в субъективном ведении ответственных лиц и достаточно одного уровня “сотрудник - согласующий”. Суть организации процесса сводится к проставлению соответствующих флагов в правах доступа у сотрудников. С этого момента все покупки у сотрудника, действия которого следует ограничить, уходят в специальный раздел тому сотруднику, который имеет право принимать решения.  Только после того, как согласующим проставлен маркер – согласие на покупку, поездка возвращается инициатору согласования и становится доступной оплата. Как было указано ранее, на момент согласования предложенной поездки выбранные элементы маршрута резервируются до момента бронирования.
Схемы согласования. Данный вариант подходит компаниям, где также принятие решения о возможности покупки той или иной услуги находится в субъективном ведении ответственных лиц, но уровней “сотрудник - согласующий” больше одного, а также структура цепочки принятия решения более сложная: есть деление на отделы, центры затрат и т.д. Здесь доступна более тонкая настройка функционала:
- возможность создания неограниченного количества шагов в схеме;
- доступно указание нескольких согласующих на одном шаге;
- настройка необходимости согласования всех или одного из списка;
- указание не конкретного лица, а его роли в организации;
- шаг в согласовании может быть необязательным;
- шаг может применяться только при определенном условии;
- и т.д.
Тревел-политики. Данный вариант подходит организациям, где условия, при которых те или иные услуги доступны для покупки, четко обозначены и типизированы. Например, по стоимости, по направлениям и населенным пунктам, по длительности, по заблаговременности покупки, по возвратности тарифов, по наличию НДС, классу обслуживания\номеров и т.д.
Бывают форс-мажорные ситуации, когда необходимая услуга не вписывается в рамки тревел-политики. Например, когда остался только один тариф авиабилета, по стоимости превышающий разрешенный максимум. А необходимость данного перелета значительней, чем разница в цене. В таких случаях, у пользователя всегда есть возможность инициировать использование механизма согласования.
После согласования предложения поездки осуществляют бронирование ранее зарезервированных элементов маршрута посредством блока бронирования (103) и присваивают метку бронированию и\или пользователю.
Дальнейшее сопровождение забронированного предложения поездки, связанного с изменением элементов маршрута или уточнением элементов маршрута или оповещением, касательно элементов маршрута, осуществляют посредством чат-бота или голосового помощника через блок поддержки вторичных операций (104).
Полностью автоматическая и настроенная напрямую интеграция позволяет обменивать и возвращать билеты. Она распознает тарифы в неструктурированном виде, как описано ранее, разные у каждой компании, и позволяет проводить возвраты/обмены без участия человека. Пользователю необходимо лишь инициировать запрос на вторичную операцию через терминал пользователя (110). Сервер (100) пошлет запрос поставщику и услуга будет отменена в соответствии с тарифом. В случае обмена необходимо будет указать параметры обмена и чат-бот/голосовой помощник (в зависимости от способа обращения клиента: в он-лайн или по телефону) организует перепоиск подходящей услуги и предложит варианты для обмена.
По завершении поездки, в автоматическом режиме, направляют отчетные документы в блок отчетности (105), на основе меток, присвоенных забронированной поездке и\или пользователю, для формирования закрывающих документов по поездке, причем отчетность формируется на основе конструктора, настраиваемого под конкретного пользователя.
В блоке отчётности (105), без участия человека, формируют весь пакет бухгалтерской документации по поездке, доступный онлайн в любой момент: акты, реестры, счета-фактуры, бланки билетов. Бухгалтерские документы доступны в нескольких форматах: pdf, xlsx, xml.
Блок отчётности (105) включает конструктор, с помощью которого можно настроить формирование пакетов закрывающих документов в любом разрезе. Разделение отчетности доступно по любой характеристике: по услугам, по видам операций, по включенности НДС и т.д. Периодичность также может быть выставлена любая.
В блок отчетности (105) интегрирована система электронного документооборота. Каждому клиенту в зависимости от выставленной периодичности отчетности отправляется весь пакет закрывающих документов в электронном виде, защищенный соответствующим образом. А также присутствует возможность прямой интеграции с программой автоматизации деятельности предприятия “1С”.
Для авиабилетов есть возможность формировать справки по перелетам. Для подтверждения факта перелета ранее нужно было, чтобы каждый сотрудник сохранял посадочный талон. В предлагаемом решении осуществляют опрос поставщиков в режиме реального времени и сохраняет статусы по перелетам. На их основе формируются справки о том, был ли использован тот или иной билет. Такие справки заменяют посадочные талоны и избавляют пользователей от необходимости их сохранять.
Предлагаемое решение дополнительно содержит блок аналитики (106), позволяющий агрегировать данные по командировкам и на этой основе принимать стратегические решения, оптимизировать работу по планированию и организации командировок.
Аналитические отчеты составляются на основе анализа больших данных, собираемых в момент каждого поиска и покупки, а именно:
1) по географии поездок;
2) по видам услуг;
3) по датам;
4) по сотрудникам;
5) по пользовательским аналитикам. Данная аналитика индивидуальная, пользователь сам может настроить необходимые критерии для формирования аналитического отчета. Примером таких отчетов может быть Центр затрат.
Аналитические отчеты могут быть использованы при формировании отчетности, что предоставляет широкие возможности для анализа любой глубины и сложности.
На Фиг. 2 далее будет представлена общая схема вычислительного устройства (200), обеспечивающего обработку данных, необходимую для реализации заявленного решения.
В общем случае устройство (200) содержит такие компоненты, как: один или более процессоров (201), по меньшей мере одну память (202), средство хранения данных (203), интерфейсы ввода/вывода (204), средство В/В (205), средства сетевого взаимодействия (206).
Процессор (201) устройства выполняет основные вычислительные операции, необходимые для функционирования устройства (200) или функциональности одного или более его компонентов. Процессор (201) исполняет необходимые машиночитаемые команды, содержащиеся в оперативной памяти (202).
Память (202), как правило, выполнена в виде ОЗУ и содержит необходимую программную логику, обеспечивающую требуемый функционал.
Средство хранения данных (203) может выполняться в виде HDD, SSD дисков, рейд массива, сетевого хранилища, флэш-памяти, оптических накопителей информации (CD, DVD, MD, Blue-Ray дисков) и т.п. Средство (203) позволяет выполнять долгосрочное хранение различного вида информации, например, вышеупомянутых файлов с наборами данных пользователей, базы данных, содержащих записи измеренных для каждого пользователя временных интервалов, идентификаторов пользователей и т.п.
Интерфейсы (204) представляют собой стандартные средства для подключения и работы с серверной частью, например, USB, RS232, RJ45, LPT, COM, HDMI, PS/2, Lightning, FireWire и т.п.
Выбор интерфейсов (204) зависит от конкретного исполнения устройства (200), которое может представлять собой персональный компьютер, мейнфрейм, серверный кластер, тонкий клиент, смартфон, ноутбук и т.п.
В качестве средств В/В данных (205) в любом воплощении системы, реализующей описываемый способ, должна использоваться клавиатура. Аппаратное исполнение клавиатуры может быть любым известным: это может быть, как встроенная клавиатура, используемая на ноутбуке или нетбуке, так и обособленное устройство, подключенное к настольному компьютеру, серверу или иному компьютерному устройству. Подключение при этом может быть, как проводным, при котором соединительный кабель клавиатуры подключен к порту PS/2 или USB, расположенному на системном блоке настольного компьютера, так и беспроводным, при котором клавиатура осуществляет обмен данными по каналу беспроводной связи, например, радиоканалу, с базовой станцией, которая, в свою очередь, непосредственно подключена к системному блоку, например, к одному из USB-портов. Помимо клавиатуры, в составе средств В/В данных также может использоваться: джойстик, дисплей (сенсорный дисплей), проектор, тачпад, манипулятор мышь, трекбол, световое перо, динамики, микрофон и т.п.
Средства сетевого взаимодействия (206) выбираются из устройства, обеспечивающий сетевой прием и передачу данных, например, Ethernet карту, WLAN/Wi-Fi модуль, Bluetooth модуль, BLE модуль, NFC модуль, IrDa, RFID модуль, GSM модем и т.п. С помощью средств (205) обеспечивается организация обмена данными по проводному или беспроводному каналу передачи данных, например, WAN, PAN, ЛВС (LAN), Интранет, Интернет, WLAN, WMAN или GSM.
Компоненты устройства (200) сопряжены посредством общей шины передачи данных (210).
В настоящих материалах заявки было представлено предпочтительное раскрытие осуществление заявленного технического решения, которое не должно использоваться как ограничивающее иные, частные воплощения его реализации, которые не выходят за рамки испрашиваемого объема правовой охраны и являются очевидными для специалистов в соответствующей области техники.