Смотрите «Дом Дракона» 22 августа в подписке Плюс Мульти с Амедиатекой на Кинопоиске
«Дом Дракона»
Смотрите в подписке Плюс Мульти с Амедиатекой на Кинопоиске
Доступно на Кинопоиске по Подписке Плюс Мульти с Амедиатекой или при наличии Доп. опции "Амедиатека". Условия: clck.ru/FMQND.
Доступно на Кинопоиске по Подписке Плюс Мульти с Амедиатекой или при наличии Доп. опции "Амедиатека". Условия: clck.ru/FMQND.
18+

Классика жанра

Обычная постановка на создание сайта для продажи билетов (терминология, орфография и пунктуация автора):

«Необходимо разработать одностраничный сайт с возможностью покупки билетов на мероприятие. По типу онлайн-покупки билетов в театр (есть даты, есть схема зала. Выбрал места, нажал на нужное количество квадратиков, внизу высветилась сумма, нажал оплатить, ввел номер карты, получил отбивку с билетами на введенную электронную почту)»

Похожие тексты мне часто попадаются на различных фриланс биржах, на разных языках. Ни чего не имею против ни таких текстов, ни заказчиков, их размещающих. Но, на основании большого опыта в этой сфере, хочу внести ясность в то, ЧТО в реальности стоит за словами этой постановки.

«По типу онлайн покупки билетов в театр…»

Онлайн покупка билетов потребует создания корзины с выбранными билетами, создания заказа, который будет отправлен в эквайринг банка, и далее, через подключенного Оператора Фискальных Данных (ОФД), на онлайн кассу, которая создаст чек и отправит его на почту покупателя. Это потребует от заказчика заключить договор с банком и ОФД, создать, настроить и зарегистрировать кассу.

Весь этот функционал, от корзины до кассы должен работать на backend’е (сервере), а не на frontend’е (сайте). Например, корзина и заказ существуют на сервере, а сайт их просто отображает. Информацию о заказе отправляет в банк сервер, где реализован протокол эквайринга.

«…есть даты, есть схема зала.»

Очевидно, что для продажи билетов нужна информация о событии, его дате и месте проведения, о схеме зала с местами. Всю эту информацию надо ввести и сохранить в базе данных. Причем, схема зала в определенном формате (например SVG) )должна содержать места с координатами (сектор, ряд, место), ценовые категории и тарифы, например, взрослый, детский, льготный и т.д. Необходим функционал для управления доступностью мест, изменения ценовых категории и тарифов «на лету». Все это задачи для серверной части проекта.

Схемы в платформе BIL24.pro

«…выбрал места, нажал на нужное количество квадратиков»

Схему нужно получить по API от сервера, показать покупателю, «оживить» ее скриптом, чтобы можно было выбрать места. Также по API необходимо забронировать места на время покупки (чтобы их не купил кто-то другой), сформировать из них заказ и подготовить его к отправке в эквайринг банка. Это основной функционал билетного процессинга - сложной штуки, которая, в том числе, управляет статусами мест (свободно, забронировано, продано), и статусами билетов (оформляется, оплачен, возвращается, возвращен). Здесь большой простор для того, чтобы сделать плохо, например, как описано в этой статье

Места и билеты – это разные сущности. На одно место, например, сектор партер, ряд 1, место 17, может быть продано несколько билетов (удивительно, да?). У каждого билета будет свой уникальный номер. При этом действующим билетом гарантировано будет только один, только с ним можно будет пройти через Систему Контроля Доступа (СКД) в зал. Остальные билеты получаются в процессе неоднократных покупок и возвратов, что является нормой на билетном рынке.

«….внизу высветилась сумма, нажал оплатить»

Обычно, это называется корзина, где представлены все места, выбранные покупателем. После нажатия оплатить будет сформирован заказ, который отправляется в банк по протоколу эквайринга. В случае успешной оплаты, на эти места будут выпущены билеты, сформирован и выслан кассовый чек. Если оплаты не последует, транзакция откатится, и места будут возвращены в продажу.

Пример корзины на сайте eventscanner.ru

По закону, покупатель билетов должен получить кассовый чек. Данные чеков автоматически сохраняются в налоговой. Правильный учет налогов и внешний вид чека зависит от важных параметров. например, агентского признака и системы налогообложения. Важно предусмотреть их настройку.

Панель настройки фискальных данных в платформе BIL24.pro

«…получил отбивку с билетами на введенную электронную почту»

Вишенкой на торте успешной транзакции, проведенной билетным процессингом с привлечением банка и ОФД, является отправка сформированных для покупателя билетов через электронную почту или мобильные мессенджеры. Для этого нужно провести покупателя через простую регистрацию, например, подтвердив его электронную почту или телефонный номер. Естественно, большая часть этого функционала реализуется на сервере.

Что не вошло в постановку

Многие важные вещи не вошли в постановку, например, такие как: выгрузка билетов в Систему Контроля Доступа (СКД) площадки, личный кабинет покупателя билетов, интерфейс для возврата билетов, отчетность и статистика продаж, функционал для отмены и переносы событий, возможность открыть продажу билетов для других билетных агентов.

Также следует сразу продумать действия в ситуации, если изменятся протоколы эквайринга и/или ОФД, если из-за санкций закроют доступ к облачному хранилищу или используемой базе данных, а также понять, сколько будут стоить доделки/переделки и поддержка такого проекта.

Вывод

В качестве вывода предложу две более верные постановки, прочнее связанные с реальностью, чем та, что приведена в начале статьи:

  1. Необходимо разработать и внедрить новую билетную систему.

  2. Необходимо создать сайт для продажи билетов, интегрированный с такой-то билетной системой или платформой, выступающей в качестве backend’а проекта.

Первый случай – это много времени, денег и рисков, о чем заказчик и исполнитель могут не догадываться в начале проекта. Второй случай - это оптимальное решение, почитать о котором можно в статье «Хочу свой сайт для продажи билетов…»

0
24 комментария
Написать комментарий...
Аккаунт замороженАндрей

По идее, что Вы описали это из требований заказчика нужно составить ТЗ и пояснить заказчику, чего как и сколько. Я всегда думал, что в идеале под это в больших конторах есть отдельно проджект менеджер или кто-то, кто совместно с разрабами будет это делать. Ну если фриланс то Вы сами себе проджект менеджер)
Ну а так, вроде бы типичная постановка задачи заказчиком, он то не обязан знать всех тонкостей. Тут ещё хорошо описали относитеьно. Это бывает ещё хуже, аля "хочу чтобы была кнопка, на неё жмешь и все красиво")

Ответить
Развернуть ветку
Александр Орлов
Автор

Вы все верно написали, заказчик не обязан. И некоторые заказчики с такими постановками впоследствии стали нашими долгосрочными клиентами. Поэтому я всегда отношусь к ним с уважением.

Вот, собственно, чтобы много раз не объяснять разным заказчикам "где собака зарыта", чтобы защитить их от бездумной траты времени и денег, я и написал эту статью.

Ответить
Развернуть ветку
Аккаунт замороженАндрей

Ну за статью респект в любом случае!

Ответить
Развернуть ветку
Александр Орлов
Автор

Спасибо

Ответить
Развернуть ветку
Dennis Prochko
Но, на основании большого опыта в этой сфере, хочу внести ясность в то, ЧТО в реальности стоит за словами этой постановки.

что нужен сайт симулирующий продажу билетов с кнопкой приема денег через яндекс с населения на частное лицо и никаких билетов на самом деле не нужно.

Ответить
Развернуть ветку
Александр Орлов
Автор

а-а, в этом случае понятно )). Потом покупатели билетов пишут в приемную vc, что концерта не будет, билеты не возвращают.

Ответить
Развернуть ветку
Александр

так это вы про банк написали

Ответить
Развернуть ветку
Dimoniada

Спасибо за habr на минималках)

Ответить
Развернуть ветку
Лео

без ТЗ-результат ХЗ, классика

Ответить
Развернуть ветку
Sasha Lander

Спасибо за статью. С некоторой грустью узнал себя! :) Александр, а можно будет обратиться к вам если соберусь делать проект? Чтобы грамотно создать ТЗ, выбрать оптимальный стэк, и потом контролировать процесс разработки?

Ответить
Развернуть ветку
Александр Орлов
Автор

Да, конечно обращайтесь. Спасибо.

Ответить
Развернуть ветку
Sasha Lander

Отлично!

Ответить
Развернуть ветку
Валентин Потапов

Тут есть еще нераскрытая и не реализованная пока никем тема/ниша. Если упрощенно. Раньше было окошко в кассе и все там обилечивались. Было единое управление билетным пулом в руках начального владельца билетов. Потом появились агенты по продажам со своим бэками, условиями и комиссией. А бэк в кассе никто толком ( с апи для агенств, управляемым пулом мест и динамическим определением цены для агенств ) не реализовал.

Ответить
Развернуть ветку
Александр Орлов
Автор

У BIL24.pro есть приложение Cassa для этих целей. В нем можно продавать билеты на любое событие, загруженное в практически любую билетную систему. Лишь бы был договор на продажу таких билетов. Собственно, все так и происходит, и уже довольно давно...

Список билеток в которые есть шлюзы на картинке:
https://bil24.pro/images/slide7v11.jpg

Ответить
Развернуть ветку
Валентин Потапов

Да, архитектурно так. Но с бизнесовой точки это стороннее проприетарное saas решение для кассы, но не в кассе.

Ответить
Развернуть ветку
Александр Орлов
Автор

Тут выбора нет. Квоты ушли в прошлое уже лет 7 как. Все продают билеты из общего билетного пула, общей билетной массы, кто как называет. Без квот, конкурентно и в режиме реального времени. Соответственно, каждый билет продаваемый в кассе нужно минут на 10-20 забронировать в далекой внешней билетной системе,, а потом провести в ней же.. Это под силу только облачному решению, платформе, с тру-платформенной бизнес-моделью. Быстрому и надежному. Способному обслуживать десятки тысяч касс. Лишь бы у них был интернет.

Ответить
Развернуть ветку
Александр Петренко

Этим заказчикам нужно совершенно другое, они создают мнимые билетные сайты, а по факту просто воруют деньги. Им не важно какой у вас бэкэнд, кластер, система управления очередей и прочее. Склепать сайт - спиздить деньги - профит.

Ответить
Развернуть ветку
CUYS.ru

Я выше как раз описал свое видение проблемы.

Ответить
Развернуть ветку
CUYS.ru

Вообще проблему и предложение озвучено верное, точнее ход мыслей верный. Возможно капот данной тематики тянет на отдельную статью не только на всеми любимым VC (не скрою что с непонятными блокировками аккаунта, но не суть vc есть vc). Суть в другом. Вот мы все с вами говорим что нужно сделать то то как описано выше. А не сделать ли вообще такую тему, что для начала продумать некий алгоритм:

1. Кто учился например на программиста.
2. Внести его в отдельный реестр. Предоставить некий паспорт или как-то назвать это документом.
3. Команду разработчиков, где он создаёт данный ресурс, оплаченный например за счёт нас налогоплательщиков.
4. Все будет кристально открыто, кто и как принимал участие в разработке данной технологии.
5. Навсегда платить (пускай это будет до смерти, извините за такие слова) данным разрабам (дизайнерам, верстальщика, сео и прочее прочее) да пускай 0.0001% с каждого проданного белета через общую систему.
6. Что в итоге мы все получим? Не будет всех этих +100500 заданий. Будет по крайне мере какой-то реестр, будет единый формат, будет оплата длящаяся пожизненно кто участвовал в разработке, в конце концов будет понятно, что нет смысла сидеть и высижывать в офисе или на удаленке и тратя лучшие свои года жизни, на разные прихоти рынка. А получать пассивный заработок каждую не знаю неделю и жить по человечески.

Я очень грубо выразил свою мысль, очень и очень, но смысл я думаю понятен. Так как даже самый крутой прогер, лет за 5 простой начнёт выгорать от все рутины работая на зп и фриланс. Почему нельзя создать новую модель заработка для всех?

И ещё насчёт реестра, сделать его в виде древовидной темы, как-то разграничить и прочее. Но думаю до этого ещё далеко, наверно через 5-7 поколений только до этого дойдёт и к сожалению не увидим, как наши дети не будут сидеть в офисе с понедельника по пятницу или брать на фриланс заказы, чтобы прокормить свою семью и помочь родственникам.

Ответить
Развернуть ветку
Dennis Prochko

миллениалы изобрели сталинскую шарашку

https://ru.m.wikipedia.org/wiki/%D0%A8%D0%B0%D1%80%D0%B0%D1%88%D0%BA%D0%B0

Ответить
Развернуть ветку
И животноводство
1. Кто учился например на программиста.
2. Внести его в отдельный реестр. Предоставить некий паспорт или как-> то назвать это документом.

А что делать с теми, кто учился на программиста, но пошел работать консультантом в Связной? (из моего потока достаточно много таких, как ни странно) А что делать с теми, кто не учился на программиста, но 10+ лет работает программистом и дорос аж до техлида? (среди моих знакомых и такие есть)

Ответить
Развернуть ветку
CUYS.ru

Вроде как безработные гоняют на феррари по Москве, как раз что-то типо реестра или поднаготной в будущем вести, не знаю как это будет называться, но что то типо общей базы данных. Где, что, когда и почему. При рождении глаза открылись, уже по сути же знают какой роддом, время, место рождения, локация и прочее. Здесь тоже самое но конструкция масштабней в тысячи раз.

Ответить
Развернуть ветку
И животноводство

А ты точно на мой комментарий отвечаешь?

Ответить
Развернуть ветку
Взрослый микроскоп

за недоКоммуникацией подрядчика и заказчика можно наблюдать вечно

Ответить
Развернуть ветку
Читать все 24 комментария
null