Тех. реализация продажи билетов на мероприятия

Что значит "уточнить техническо-организационные моменты реализации" ? За Вас ТЗ написать что ли? Думаю, что в этом направлении никаких стандартов нет, и каждый ведёт учёт по своему (начиная от 1С и заканчивая бумажным блокнотом). ИМХО тут нужно начинать программировать (благо ничего сложного на первый взгляд не наблюдается), а затем уже "наворачивать" по мере необходимости.

Я б наваял самописа в качестве ИМа... Привычка с детства - изобретать велосипеды:)

Помимо ИМа делаем еще 1 скриптик, который отвечает за синхронизацию.

script.php

if (isset($_GET['get']))
{
отдаем тому самому внутреннему ПО данные о уже купленных билетах.
}

И что-то аналогичное сделать у внутреннего ПО, чтобы наш ИМ мог чекать билеты.

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

А вообще, я б все сделал на одной общей БД. Тогда вопрос синхронизации вообще отпадает. Возможно и придется делать какой-то "мост" между 1С(или еще чем-нить) и нашей БД на сервере, но я думаю, что это небольшая плата за синхронизацию.

Если делать с общей базой, то можно билеты выгружать в базу с основного ПО(оффлайн продажи через которое идут), а ИМ просто будет их продавать. Для билетов купленных в интернете можно делать че-то типа ТОКЕНов, и говорить юзерам - вот Вам код билета, распечатайте его плиз:) Ну а на входе в кинотеатр или куда еще чекать такие билеты.

Ну эт я так, идеи первых 5-ти минут раздумия:)

Значит услышать опыт\мысли\варианты решений для указанных задач от тех спецов, кто уже делал\понимает о чем речь.

не-не.. Речь не о том "на чём сделать?" Речь больше "как оно работает в реальности?" и "в чём отличия от товарного ИМ?" (тех. нюансы)

Ну основное отличие в синхронизации, эт как бы понятно:)

Я просто в глаза ни разу 1С не видел(я имею ввиду кишки), и поэтому хз как она работает. Если она не захочет работать с удаленной БД, то можно так:

БД на сервере<=>Софт<=>1C

Софт - например прога на делфи, которая отвечает за связь с БД и поддержание ее в актуальном состоянии. Ну а 1С-ка будет использоваться только для бухгалтерии.

Ты хочешь делать что-то универсальное(сервис), или это под 1 конкретного человека? Если универсальное, то тут чуток сложней, если же под 1 конкретную контору - 1 раз настроил взаимодействие БД и офлайнового ПО и забыл.

ЗЫ. не думаю, что у тебя эта задача вызовет проблемы:)

UPDATE:

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

Как по мне, так основная задача - грамотная архитектура БД, то есть, чтобы когда появился скажем новый объект(раньше были билеты в цирк, а добавились билеты на уличные представления с гастролями по стране), не начались пляски с бубном, типа как это уложить в БД, e.t.c.

Да.. видимо я как-то не понятно донёс чего я хочу от топика. ;)

Не сервис.

Можно сказать "под человека". Но сейчас меня интересует не то, что в конкретном случае, а .. ну хз как ещё выразиться.. "структура взаимоотношений ПО" что ли.. (мне казалось "техническо-организационные моменты реализации" как раз наиболее точно описывают то, что я хочу от топика).

Попробую ещё раз.

Все более-менее представляют что значит продажа билетов в кинотеатрах? Т.е. имеется некая база переменных данных - сеансов (фильмов-времени) и постоянных - залов и мест в них.

Если брать обычный товарный ИМ, то получается каждый билет - уникальный товар (по совокупность данных). С этой т.з. - не забивать же каждый товар в базу. (хотя мб так и есть - это один из многочисленных вопросов).

Второе - бронирование и сдача\отказ от покупки (если бронировалось) билетов или неявка зрителя до положенного срока (отсюда и актуализация данных (применяется ли?) и % от суммы и др. моменты).

Ну и тд и тп.. Вот эти "механизмы" у меня пока в тумане..

(А ведь тоже поначалу показалось - вроде бы ничего эдакго. А когда начал рисовать...)

Особенно не понятно с гастролёрами. Начиная от того, один и тот же театр (к примеру) может выступать одновременно (разным составом) в разных городах и заканчивая разными залами (кол-во мест, внутренний учёт билетов и тп)

И, да, немаловажный момент - сторонние сервисы (типа бигбилета). Какие они, как с ними работать, где описания и правила сотрудничества?

Это мб и надо было задать в ветке про ИМ, но я там как-то не видел киношников\театралов\циркацей ;). Да и меня больше ответы технарей интересуют, а не менеджеров\владельцев с ответами типа - "вот там нам всё сделали"

Ну поэтому я и говорил, что делать свой ИМ, с заточкой именно под конкретную ситуацию. То есть делаем таблицу places, которая хранит в себе данные по местам провидения мероприятий.

В интерфейсе магазина на чем-нить красивом типа Jquery делаем страничку добавления нового представления:

<select> это список мест проведения из таблицы places

Ну и какая-нибудь хитрая форма(тут уже полет фантазии, как самое примитивное - 2 инпута: количество рядов в зале и количество мест в каждом ряду), которая в одно движение мышью позволит создать все возможные места.

Далее все эти места можно как-то сгруппировать при необходимости, ну чтобы не вбивать 10 разных цен для 2000 мест.

А вопросы про гастролеров - это все зависит от умения грамотно спроектировать БД;)

Ну глубоко же копашь, очень глубоко. ;)

Лопаты и выбор поставщика саженцев сейчас не интересуют. Пока речь только о плане сада и теоретизирование на тему "какой компост лучше". ;)

Начинать плясать от ПО, уже имеющегося в компаниях. Некоторое время назад довольно часто можно было встретить свои разработки (вроде такой) Как правило, у них есть API, которое можно настроить на передачу информации о свободных/занятых местах и приём инфы о бронировании/оплате.

товар = {место, время}

место = {зал, ряд, место} // в терминологии не силён.. "правильно" обозвать

Процедура бронирования, оплаты, отказы от брони скорее организационная - у каждой организации своя. Как правило, за ХХ минут до начала бронь освобождается, а за YY часов до начала не продаётся. Под неё подстраиваться.