Операторы осуществляют оформление документов на продажу, в принципе, неважно даже чего - билетов на проезд, в кинотеатр, мест на парковку... Главное, что бы как только произошла выборка товара в документ - он (товар) становился недоступен для выбора другого оператора. Сразу проводить документ - не комильфо, покупатель может отказаться - тогда бронь снимается. Пока рассматриваю вариант независимого РС, в который пишется бронь и чистится либо в момент проведения/закрытия без сохранения + регламентное задание раз в час. Может есть другие предложения?

Можно накладывать объектную блокировку.
Меньше нагрузка на базу и меньше проблем с отвалившимися клиентами.

(0) топик ни о чем
нет требований на многопользовательскую работу и отражение резервов

поэтому обсуждать архитектуру хранения данных бессмысленно

(1) бред
(0) норм

(0) ну и конечно независимый регистр без документа и версионирования для резервов не подходит

(2) Ты не прочитал что ли? Все есть.

(5) ты точно не читал, ничего нет

(3)+ обязательно писать в этот РС время блокировки и менеджера, чтобы можно было корректно чистить потом

Резервировать при интерактивном подборе? *овнокод

Нужно как на сайтах кинотеатров или выбора мест в самолете - чтоб ты видел, что кто-то другой на это место тоже тыкает (выбрал в кандидаты к брони)

Но пока не бронь не зафинализирована, запрещать другому выбрать это же место никак нельзя

(9) "чтоб ты видел, что кто-то другой на это место тоже тыкает" == резервирование

Запрещать или нет, это детали.

(11) Нужно иметь два статуса резерва: "возможно будет зарезервирован" и "уже зарезервирован". И конечно же твое второе предложение ошибочное.

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

Если есть количественный учет, то необходим регистр накопления.
Делаете его подчиненным регистратору.
При вводе очередной строки (или по отдельной кнопке, или...[тут надо подумать - в какой именно момент производится бронирование]) выполняется запись в этот регистр.
Вне обработки проведения(!). Типа записать документ (Если Новый()), СоздатьНаборЗаписей, установить отбор по регистратору, заполнить бронируемыми данными, Набор.Записать().
Во всех отчетах и обработках подбора по остаткам учесть наличие забронированного товара в этом регистре (из остатков по основному регистру вычесть остатки из регистра забронированных товаров).

А при выполнении проведения документа проследите, чтобы у это регистра был признак Записывать = Истина, чтобы записался пустой набор записей, таким образом произведя очистку бронирования окончательно проданного товара.

предполагается что размер кэша не более десятков или сотен позиций.

(14) какой нафиг отбор по регистратору если 100 пользователей...

(7) Чистка брони таким образом - отдельная головная боль.
Должны быть четко определены критерии бронирования и время (период) бронирования.

обычная задача про занятость помещений и время...

(16) А при чем тут вообще пользователи? Хоть 3, хоть 30, зоть 300, хоть 3000?

(18) Да, если нет количественного учета.
Если каждый объект индивидуален и бронирование производится только в разрезе объекта.
Если объекты имеют количественный показатель, то это совершенно другая задача.

(20)какой количественный учет? ты бредишь?

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

(21) Автор ветки не конкретизировал задачу и слился.
Я всего лишь обратил на это внимание. Что задача может решаться другим способом - в зависимости от одного ма-а-а-а-а-ленького нюанса.

(22) Про ячейки это ты сам придумал? У автора в (0) четко написано: "ТОВАР".

+ к (24) И кто тут бредит?....

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

(21) не слился. Я тут и все читаю, просто медленно.

(0) В принципе - направление верное...
Посмотри, как сделан учет по партиям в типовых.
Резерв - регистр (естественно, если товар в регистре - не доступен). Проведен док-т - в регистр. Нет оплаты, отказ и пр. - отмена док-та - очистка регистра (товар становится доступен).
Особое внимание - ко всяким нюансам и исключениям.

(18) задача та. Где почитать про ее реализацию :)

(0) У вас атомарные операции - каждая бронь должна быть отдельным документом.

(30) постоянное бронирование - да. Здесь уже отметили и правильно сформулировали - меня интересует бронь временная - до момента проведения документа.

(25) задача про бронирование и доступность а не про торговлю в розницу.
(30) Вместо регистра предлагаю использовать глобальную переменную - КэшСвободныхМест - хоть структуру, хоть списокзначений, которую все могут читать и записывать. Снимается проблема грязного чтения и конфликта блокировок как в случае регистра сведений. Регистр накопления не взлетит ибо нужен регистратор.

и вообще уже есть 1с Театр https://solutions.1c.ru/catalog/theatre/features - посмотрите там

(31) Так проводите каждый документ как вам надо, согласно статуса - постоянная, временная.

(33) отдельное спасибо, посмотрю.

(31) У вас по сути каждая строка "табличной части" должна быть отдельным документом.

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

(32) > задача про бронирование и доступность а не про торговлю в розницу

Это стало ясно только после поста (29). До этого момента автор мееееедлееееенно читал )))

Замечания (14)(20)(23)(24)(25) снимаются.

(36) тоже мысль. подумаю. спасибо.

(32) "Глобальная переменная" это что, в терминах платформы? Где хранится?

(38) прошу прощения, но телефон стали с утра разрывать.

(40) учите матчасть http://blog.it-terminal.ru/helpfull_video/globalnye-peremennye-i-modul-formy-v-1s-8-3.html

(0) Sorry, но Ваша тема, мягко говоря, не претендует на оригинальность. Если её, не изменяя сути, представить несколько в другом виде. В своё время решал проблему:

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

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

Соответственно пока заявка оформлена, но ещё не согласована/отгружена, - она может быть оперативно пересмотрена (как со стороны покупателя, так и по инициативе менеджера).

Всего три регистра, обработка подбора и чат-сообщений.

(43) я на оригинальность и не претендую, а прошу совета. Любая подсказка - большое спасибо.

Если представить, что "билет на спектакль" - это штучный товар, который поступает на склад в количестве одной штуки, то торговля билетами в театре ничем не отличается от оптовой торговли. Почему акцентирую внимание на этом? потому что можно искать решения в "не смежных" областях.

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

(45) задача не продать пачку билетов, а продавать в конкурентном режиме билеты на определенные места

кинотеатры и ржд сейчас задачу решают через временный резерв , который открывается на время и если не закрыт оплатой , то снимается.
Самолеты например продают на софте который слава богу не 1с. Т.е. сколько он там может держать открытых сессий не знаю, но точно выдерживает нагрузку в десятки тысыч одновременных подключений. (но круче ржд все равно думаю ни у кого не было .. именно в силу зон и кучи поездов)

(48) слава богу мне столько единовременных не надо - от силы 10, так что надеюсь 1С будет достаточно :)

(48) ну вот и открылась ниша где можно запилить свою нетленку на 1с с вставками на ассемблере для скорости ))

(42) А без видео ссылка есть, текстом? Или своими словами опиши. Напомню на всякий случай, нам нужно нечто, доступное всем сессиям.

(47)

Билет на место: свободен/забронирован/продан/разбронирован/возвращён(свободен)...

Товар: в свободном остатке/забронирован(заявлен) и временно недоступен/отгружен/заявка не подтверждена/возврат от покупателя...

В чём принципиальная разница?

(0) во нашел http://catalog.mista.ru/public/201081/ скачай. допили. делов то

(43) И где хранятся подобраные в документ, но не записанные позиции?

ну или http://catalog.mista.ru/public/194751/ для ретроградов типа Серг_1960 ))

(0) Почему не делать документ резервирования, а потом когда уже пройдет продажа- продажу?

(56) ну почему не делать. в (36) уже предложили. Буду думать.

(53) и (55) поглядим. Делов то достаточно, но будем почитать :)

(53) Что-то там не видно временного резерва...

(57) ТЫ написал:
> Сразу проводить документ - не комильфо, покупатель может отказаться - тогда бронь снимается.

Если будет документ резервирования/заказа, а продажа только потом, то почему бы не проводить?

(52) в ваших понятиях место - это товар? элемент номенклатуры?
не путайте место и билет. На одно место можно продать хоть 100 билетов. а оно одно

(55) Вах, я ретроград :) Хмм... ну да, как-то так :)

У меня РИБ на восьмерке работала по расписанию, когда этого ещё не было в типовых конфигурациях, ни РИБ, ни регламентов. А оперативным резервированием в онлайн-режиме в редактируемых документах и функционал соответствующего окружения - мало кто и сейчас этим похвастаться может.

(60) проводить основной документ не хочется. Счас начнут ворчать - но не хочется нарушать нумерацию. А вот к табличной части основного привязать документы резерва и играть с ними теоретически возможно. Поэтому как вариант отложил.

(60) +1

На данном участке процесса - два этапа: резервирование и подтверждение/отказ.
Не вижу почему нельзя сделать на эти два события два документа.

К тому же сюда хорошо ложаться движения по регистру накопления. Резервирование +1, подтверждение/отказ -1.

*ложатся

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

(66) при разработке "на лету" без подробного планирования можно действительно "налететь".
Достаточно очередному падавану пропустить строчку

НаборЗаписей.Отбор.блаблабла.Установить();

и всё - регистра нет

да уймитесь вы с документом резерва. Количество всегда =1. нужно учитывать занятость позиций, ячеек склада/банка/стоянки, места театра, а не билеты. Занято/нет. а не остаток мест на складе ))

(68) это сейчас оно =1, а через месяц начнется

"а вот мы тут придумали.. пусть места составные будут..."

(69) ну ... комплектация мест

(68) Замени слово "резервирование" на "бронирование" если не нравится. Но в типовых конфигурация чаще используются резервирование и документы резервирования, чем использование термина "бронирование" :)

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

(71)Хорошо. озвучу ваш бред. Ячеистый склад в ЕРП. Туда положить по одному билету. Формой выбора 10 кассиров кликая мышкой создают документ резерва, в попытке проведения которого  создается резерв, который при оплате снимается. Нравицца?

(72) ну у меня такой личный опыт есть) В пору своего падаванства точно так же затёр регистр. Гребли конечно не очень много, компания очень трепетно относилась к безотказности работы, поэтому бекапились сведения каждый час. Но минут на 20 я работу всей службы доставки остановил)

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

(73) Не нравицца. Мне Ваша манера и тон не "нравицца".

А если по теме, то бронирование устанавливается на период - не успели оплатить - билет в свободном доступе.

(74) а там не было бэкапов .. плюс свалили на меня .. я три или четыре дня из каких то логов восстанавливал данные (а эт овообщето сеть ювелирная была), а потом  снова поймал это место, так как потерял данные повторно .. а вот потом уже выяснил, что связка проектировщик+программист+отдел тестирования запустил такую ерунду в базу .. хотя вот я наверно при альцгеймере такое не сделаю.

(0) Я когда делал свою гостиничную конфигу - регистр накопления использовал. Очень удобно с ним работать

(0) если интересны подробности, велком в скайп germodachter

(78) пока собираю варианты, но за приглашение спасибо. Если припрет - загляну обязательно.

(Уже уходя) Некоторые зашорены до безобразия.

Расслабьтесь, абстрагируйтесь.

Представьте что вы на 1С реализовали морской бой и все видят эти клеточки, по которым любой может стрелять, но только один раз (в одну воронку снаряд дважды не попадает). Кстати это интересное утверждение, ибо не один снаряд дважды не стреляет :)) Расслабились? Теперь можете сообща далее писать ТЗ :)

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

(81) +1

программировать надо начинать не в 1С, а сначала весь процесс продумать и в проектировщике(ну или на бумаге) схему процесса нарисовать

(82) :) наверное имел в виду "резервирование - это результат процесса бронирования"))

(0) ну без блокировок все равно не взлетит
я бы сделал бронирование при оформлении заказа до 10 минут
неперешедшие брони в состояние заказа аннулирует Фоновое задание

перед оформлением заказа проверять, не сняло ли ФЗ твою бронь... делать на РН, заблокировал, провёл, проверил остаток, ушел в минус - отказ транзакции, в ноль - ок.

(86)кто в этот РН будет писать? Открыт новый док, не записан не проведен, открывается форма подбора и клацается на Номенклатура1 в эту секунду для всех остальных должно появится отказ при дабл клике на N-минут/

(84) Нет, процесс бронирования не обязательно завершается резервированием

(87) Пусть пишут в независимый РС "Блокировки номенклатуры"

(89)Я не против.

Хех. Привыкли все работать по предоплате и перестали понимать, что бронирование - это резервирование без оплаты(до оплаты).

(0) Если товар уникальный (кол-во везде 1) то банально реквизит в справочник товаров с выбором оператора, который забронировал.

ну для билетов это не катит, там ведь зал один, а сеансов много . Т.е. там уже какая то составная ерунда появляется. Типа время, номер сеанса, номер кресла.

(93) Эта составная ерунда прекрасно влезает в один товар

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

(95) Не тупи, Товар = фильм, зал, дата, время (сеанс) + № кресла

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

(96)+ Этот товар называется "Билет", который уникально определяет все прочие реквизиты "куда и за что"

(96) ага, а потом жаба не задавит содержать справочник номенклатуры растущий со скоростью около 45000 элементов в сутки (это для кинотеатра где около 4500 кресел и около 10 сеансов за день).

(99) Какая нафик разница что растет справочник или регистр?

Все равно билеты должны иметь уникальные номера, а что имеет уникальный код?

(100) пересечение измерений, куда мы положим 0 или 1, можно подумать еще и 2.

(101) А уникальные номера как будешь делать?

Не о том думаете, народ. Как бронировать любой товар или места, давно известно. Вопрос ТС про временное, "мягкое" резервирование. Как его ставить. Когда и как проверять. Когда и как снимать.

(103) я бы забабахал ТЗ, которое одновременно живет на сервере и на каждом клиенте.

каждый клиент захватывая объект стучит в сервер.
сервер добавляет его в ТЗ и рассылает остальным клиентам.

(0) Есть готовое решение для кинотеатров. Не дешевое, но дешевле, чем решения не на 1С. Если есть интерес, пиши, мой ник псина народ ру.

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