Есть необходимость хранить места в зале. Есть залы. В них есть ряды и места. Места имеют различную стоимость, в зависимости от типа места.

Я начал делать так. Сделал справочники

Залы (реквизиты только Код и Наименование - стандартные)
ТипыМест (реквизиты Код, Наименование, Стоимость)
Места (рекв. Зал (ссылка.Залы), Ряд(число), Место(число), Тип(вот тут по идее надо выбрать только наименования из справ. ТипыМест) )

Вот думаю, правильно ли я делаю, храня стоимость типа места в справочнике. или лучше там хранить только наименования типов мест, а стоимость хранить в отдельном справ. или вообще в регистре... ?

в регистре сведений, ибо может изменяться

а что, у тебя зал размером ос страну.. упрешься в вопросы быстройдействия?

(1) в справочнике может изменяться ВСЁ! - всё хранить в регистрах сведений?

(2) Учусь как делать лучше. Пока не могу предугадать на какие проблемы наткнусь далее.

(4) в твоем случае "правильность делания" будет определяться больше не структурой данных, а грамотным интерфейсом

(3) если нужна история - то да

(5) Тогда по другому поставлю вопрос. Чтобы удобнее было выбрать тип места мне надо их наименования где то хранить. И где-то надо хранить стоимость типа этого места.

Важно ли то как я храню инфу о типах места? 2 справочника - 1 для наименований, другой для стоимости. или же 1 справочник в котором и то и то.

(6) понял, регистр когда нужна история изменения характеристик. но не думаю, что такое потребуется.

(0) Тема подробно обсуждалась на форуме , не более чем пол года назад

И еще вопрос. Стоит ли создавать документ для добавления нового места в зал. Скажем решили поставить 5 диванных места в какойнить зал, надо добавить.

Или же можно обойтись формой справочника. И документ не нужен.

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

(0) По-моему тут почти полная аналогия с номенклатурой, ценами номенклатуры и типами цен. Соответственно стоимость в РС и документ для ее ввода/изменения.

А типы мест можно пока и перечислением сделать. Потом если надо на справочник перейти.

(0) Такие задачи лучше делать с избыточной структурой данных.
Например: код места может быть такой "Зал-Ряд-Место", может быть признак "зал-ряд", может быть номер места или ряд+место. ОТ этого зависит потом те данные которые будут хранится в регистрах сведений системы:
Например:
1) "Зал-Ряд" + "Комфортность"
2) "Зал-Ряд-Место" - "Тип места"
3) "Зал-Ряд-Место" - "Вид брони", "Дата брони"
Это как лицевой счет - запихивай в него всё, мало ли что понадобится в будущем.

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

А вот еще такой вопрос. У места может быть состояние - доступно для посадки, сломано, в ремонте, ... И необходимо иметь статистику сколько каких мест имело определенное состояние в определенный период времени.

Здесь стоит исползовать РС. Нормально ли при добавлении записи в справочник программно добавлять инфу о состоянии места в РС? То есть, добавили новое место - его состояние начальное стало "доступно для посадки".

(14) Нет, добавлять в РС нужно документом.

То есть, добавление места как такового стоит тоже делать документом? В (10) говорили, что добавлять документом - это плохо:) Или же можно как то добавить новое место при помощи формы справочника и дополнительно провести документ на изменение состояния места?

(13) Как писать дело десятое, важно чтобы было легко выбрать
Полный код.
Код с рядом.
Код с залом.
Код с местом.
Код с Кинотеатром.
Код с Городом.
Код со Страной...
Сорри но, 1) Я не знаю размер вашего бизнеса...
2) Я не знаю ваши аналитики
3) Я не знаю, что поможет решить проблемы вашего заказчика
4) Я не знаю, что является задачами для вашего заказчика.
5) И наверное никогда это не узнаю ))))
(14) Не тут регистр накопления нужен...

(17) по поводу регистра - это сарказм? не совсем понимаю что можно накапливать там.

(18) Нет, никакого сарказма. Количество мест в ремонте, вам же периоды нужны и количество сколько в работе, сколько нет. А может вы на неделю зал закроете - будете менять в нем кресла.

(19) О, точно. Хорошая идея. Спасибо!

(18) Я вам и так уже много дал бесплатных советов )))

Обычно правила ценнообразования достаточно просты
типа
с 1 ряда по 4 ряд ххх тугриков
с 5 по 8 ряд yyy тугриков
и т.д.

я кода-то делал справочник с правилами ценообразования подчиненный справочнику залы

(20) Потом не стоит забывать, что места продаются не в данный момент, а на сеанс, который будет в будущем. Если что-то планируется закрыть или поставить в ремонт, то это должно быть заранее зарегистрировано, чтобы никто не смог продать билеты на места, которые окажутся в ремонте.
P.S. кроме цены - ещё нужно состояние места, которое привязано к временным интервалам (то есть сеансам) - свободно, занято, забронировано, в ремонте, демонтировано и т.п.

(23) +1
ТС нужно очень много поболтать с заказчиком в режиме "Вопрос-Ответ", описать БП и ТЗ, а пототм уже базу кодить...

Справочник - Залы с ТЧ Ряд, НомерМеста, Характеристика места,
РС периодический - изм: Зал, Ряд, НомерМеста рекв - Цена и т.д. дополнительно можно указать Характеристику

(16) наглый пиз....ж в (10) я не говорил что добавлять документом плохо. я сказал о том, что в интерфейсе кинотеатра вводить новый документ - это бяка. тот кто работать будет - он дале от понятия "ДОКУМЕНТ ДЛЯ ВВОДА НОВОГО МЕСТА" - бред полный. все должно делаться для юзера !прозрачно! через ИНТЕРФЕ!С, который представляет собой планировку кинозала.. - типа так...

(22) что-то в жизни вроде не так. Цена зависит не только от места, а от кучи еще сведений. Премьера - не премьера, 3д - не 3д, утренний сеанс или вечерний. От ряда реально мало что зависит. Почему автор привязывает цену к ряду непонятно.

сие есть рождение "1С: Управление кинотеатром"?

(28) уже есть "Продажа театральных билетов" у клиента))