Вход | Регистрация

  1  2   
1С:Предприятие ::

Метки: 

Разработка механизма бронирования

Я
   LienXo
 
22.06.18 - 08:38
Операторы осуществляют оформление документов на продажу, в принципе, неважно даже чего - билетов на проезд, в кинотеатр, мест на парковку... Главное, что бы как только произошла выборка товара в документ - он (товар) становился недоступен для выбора другого оператора. Сразу проводить документ - не комильфо, покупатель может отказаться - тогда бронь снимается. Пока рассматриваю вариант независимого РС, в который пишется бронь и чистится либо в момент проведения/закрытия без сохранения + регламентное задание раз в час. Может есть другие предложения?
 
 
   mistеr
 
1 - 22.06.18 - 08:46
Можно накладывать объектную блокировку.
Меньше нагрузка на базу и меньше проблем с отвалившимися клиентами.
   shuhard
 
2 - 22.06.18 - 08:48
(0) топик ни о чем
нет требований на многопользовательскую работу и отражение резервов

поэтому обсуждать архитектуру хранения данных бессмысленно
   butterbean
 
3 - 22.06.18 - 08:48
(1) бред
(0) норм
   shuhard
 
4 - 22.06.18 - 08:49
(0) ну и конечно независимый регистр без документа и версионирования для резервов не подходит
   mistеr
 
5 - 22.06.18 - 08:50
(2) Ты не прочитал что ли? Все есть.
   shuhard
 
6 - 22.06.18 - 08:52
(5) ты точно не читал, ничего нет
   butterbean
 
7 - 22.06.18 - 08:52
(3)+ обязательно писать в этот РС время блокировки и менеджера, чтобы можно было корректно чистить потом
   Cyberhawk
 
8 - 22.06.18 - 08:58
Резервировать при интерактивном подборе? *овнокод
   Cyberhawk
 
9 - 22.06.18 - 08:58
Нужно как на сайтах кинотеатров или выбора мест в самолете - чтоб ты видел, что кто-то другой на это место тоже тыкает (выбрал в кандидаты к брони)
   Cyberhawk
 
10 - 22.06.18 - 08:59
Но пока не бронь не зафинализирована, запрещать другому выбрать это же место никак нельзя
 
 Рекламное место пустует
   mistеr
 
11 - 22.06.18 - 09:12
(9) "чтоб ты видел, что кто-то другой на это место тоже тыкает" == резервирование

Запрещать или нет, это детали.
   Cyberhawk
 
12 - 22.06.18 - 09:19
(11) Нужно иметь два статуса резерва: "возможно будет зарезервирован" и "уже зарезервирован". И конечно же твое второе предложение ошибочное.
   kauksi
 
13 - 22.06.18 - 09:22
при открытии формы считывать доступные места в некий глобальный кэш, доступный всем пользователям, при клике - удалять его оттуда, при отмене - возвращать. также обновлять кэш при всяких операциях проведения заказа. Что использовать в качестве кэша - дело вкуса
   unregistered
 
14 - 22.06.18 - 09:22
Если есть количественный учет, то необходим регистр накопления.
Делаете его подчиненным регистратору.
При вводе очередной строки (или по отдельной кнопке, или...[тут надо подумать - в какой именно момент производится бронирование]) выполняется запись в этот регистр.
Вне обработки проведения(!). Типа записать документ (Если Новый()), СоздатьНаборЗаписей, установить отбор по регистратору, заполнить бронируемыми данными, Набор.Записать().
Во всех отчетах и обработках подбора по остаткам учесть наличие забронированного товара в этом регистре (из остатков по основному регистру вычесть остатки из регистра забронированных товаров).

А при выполнении проведения документа проследите, чтобы у это регистра был признак Записывать = Истина, чтобы записался пустой набор записей, таким образом произведя очистку бронирования окончательно проданного товара.
   kauksi
 
15 - 22.06.18 - 09:23
предполагается что размер кэша не более десятков или сотен позиций.
   kauksi
 
16 - 22.06.18 - 09:24
(14) какой нафиг отбор по регистратору если 100 пользователей...
   unregistered
 
17 - 22.06.18 - 09:24
(7) Чистка брони таким образом - отдельная головная боль.
Должны быть четко определены критерии бронирования и время (период) бронирования.
   kauksi
 
18 - 22.06.18 - 09:25
обычная задача про занятость помещений и время...
   unregistered
 
19 - 22.06.18 - 09:25
(16) А при чем тут вообще пользователи? Хоть 3, хоть 30, зоть 300, хоть 3000?
   unregistered
 
20 - 22.06.18 - 09:27
(18) Да, если нет количественного учета.
Если каждый объект индивидуален и бронирование производится только в разрезе объекта.
Если объекты имеют количественный показатель, то это совершенно другая задача.
   kauksi
 
21 - 22.06.18 - 09:29
(20)какой количественный учет? ты бредишь?
   kauksi
 
22 - 22.06.18 - 09:29
тут места (ячейки) при выборе надо проверять занята ли уже или нет,
   unregistered
 
23 - 22.06.18 - 09:31
(21) Автор ветки не конкретизировал задачу и слился.
Я всего лишь обратил на это внимание. Что задача может решаться другим способом - в зависимости от одного ма-а-а-а-а-ленького нюанса.
   unregistered
 
24 - 22.06.18 - 09:32
(22) Про ячейки это ты сам придумал? У автора в (0) четко написано: "ТОВАР".
   unregistered
 
25 - 22.06.18 - 09:33
+ к (24) И кто тут бредит?....
   Сияющий в темноте
 
26 - 22.06.18 - 09:35
Сделайте как у Ржд,обращение к элементу(у них билет)временно его блокирует,и выполнить операцию может только тот,кто заблокировал,время прошло,снова доступно всем.
И,конечно,в регистр,где можно,во-первых,отразить все услуги,доступные для бронирования,а также писать временную и постоянную блокировку(когда продали,услуга остается в регистре до оказания,чтобы в случае отказа можно было вернуть статус,а не снова добавлять в регистр)
удачи
   LienXo
 
27 - 22.06.18 - 09:35
(21) не слился. Я тут и все читаю, просто медленно.
   Масянька
 
28 - 22.06.18 - 09:39
(0) В принципе - направление верное...
Посмотри, как сделан учет по партиям в типовых.
Резерв - регистр (естественно, если товар в регистре - не доступен). Проведен док-т - в регистр. Нет оплаты, отказ и пр. - отмена док-та - очистка регистра (товар становится доступен).
Особое внимание - ко всяким нюансам и исключениям.
   LienXo
 
29 - 22.06.18 - 09:42
(18) задача та. Где почитать про ее реализацию :)
   Genayo
 
30 - 22.06.18 - 09:42
(0) У вас атомарные операции - каждая бронь должна быть отдельным документом.
   LienXo
 
31 - 22.06.18 - 09:45
(30) постоянное бронирование - да. Здесь уже отметили и правильно сформулировали - меня интересует бронь временная - до момента проведения документа.
   kauksi
 
32 - 22.06.18 - 09:46
(25) задача про бронирование и доступность а не про торговлю в розницу.
(30) Вместо регистра предлагаю использовать глобальную переменную - КэшСвободныхМест - хоть структуру, хоть списокзначений, которую все могут читать и записывать. Снимается проблема грязного чтения и конфликта блокировок как в случае регистра сведений. Регистр накопления не взлетит ибо нужен регистратор.
   kauksi
 
33 - 22.06.18 - 09:51
и вообще уже есть 1с Театр https://solutions.1c.ru/catalog/theatre/features - посмотрите там
 
 
   Genayo
 
34 - 22.06.18 - 09:53
(31) Так проводите каждый документ как вам надо, согласно статуса - постоянная, временная.
   LienXo
 
35 - 22.06.18 - 09:53
(33) отдельное спасибо, посмотрю.
   Genayo
 
36 - 22.06.18 - 09:54
(31) У вас по сути каждая строка "табличной части" должна быть отдельным документом.
   gSha
 
37 - 22.06.18 - 09:54
понятно, что у ржд все на порядок сложнее, так как их система работала когда скорости каналов были типа 300 бит в секунду , и ленты крутились в одну сторону,  а места продавались в первые часы открытия продажи тысячами..
так, что можете про них не вспоминать, так как это космос на самом деле.
Сейчас они действительно все решают через мощности, как следствие по тупизне в первые минуты , они могут соперничать только с победой - той равной нет.
   unregistered
 
38 - 22.06.18 - 09:56
(32) > задача про бронирование и доступность а не про торговлю в розницу

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

Замечания (14)(20)(23)(24)(25) снимаются.
   LienXo
 
39 - 22.06.18 - 09:57
(36) тоже мысль. подумаю. спасибо.
   mistеr
 
40 - 22.06.18 - 09:57
(32) "Глобальная переменная" это что, в терминах платформы? Где хранится?
   LienXo
 
41 - 22.06.18 - 09:58
(38) прошу прощения, но телефон стали с утра разрывать.
   kauksi
 
42 - 22.06.18 - 09:58
   Serg_1960
 
43 - 22.06.18 - 10:01
(0) Sorry, но Ваша тема, мягко говоря, не претендует на оригинальность. Если её, не изменяя сути, представить несколько в другом виде. В своё время решал проблему:

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

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

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

Всего три регистра, обработка подбора и чат-сообщений.
   LienXo
 
44 - 22.06.18 - 10:03
(43) я на оригинальность и не претендую, а прошу совета. Любая подсказка - большое спасибо.
   Serg_1960
 
45 - 22.06.18 - 10:05
Если представить, что "билет на спектакль" - это штучный товар, который поступает на склад в количестве одной штуки, то торговля билетами в театре ничем не отличается от оптовой торговли. Почему акцентирую внимание на этом? потому что можно искать решения в "не смежных" областях.
   gSha
 
46 - 22.06.18 - 10:05
все зависит исключительно от нагрузки .. чем она выше и чем медленнее каналы обновления информации о доступности, тем ее сложнее решить. С некоторого момента там без решения задач систем массового обслуживания не обойтись.
   kauksi
 
47 - 22.06.18 - 10:06
(45) задача не продать пачку билетов, а продавать в конкурентном режиме билеты на определенные места
   gSha
 
48 - 22.06.18 - 10:11
кинотеатры и ржд сейчас задачу решают через временный резерв , который открывается на время и если не закрыт оплатой , то снимается.
Самолеты например продают на софте который слава богу не 1с. Т.е. сколько он там может держать открытых сессий не знаю, но точно выдерживает нагрузку в десятки тысыч одновременных подключений. (но круче ржд все равно думаю ни у кого не было .. именно в силу зон и кучи поездов)
   LienXo
 
49 - 22.06.18 - 10:15
(48) слава богу мне столько единовременных не надо - от силы 10, так что надеюсь 1С будет достаточно :)
 
 Рекламное место пустует
   kauksi
 
50 - 22.06.18 - 10:16
(48) ну вот и открылась ниша где можно запилить свою нетленку на 1с с вставками на ассемблере для скорости ))
   mistеr
 
51 - 22.06.18 - 10:16
(42) А без видео ссылка есть, текстом? Или своими словами опиши. Напомню на всякий случай, нам нужно нечто, доступное всем сессиям.
   Serg_1960
 
52 - 22.06.18 - 10:16
(47)

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

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

В чём принципиальная разница?
   kauksi
 
53 - 22.06.18 - 10:17
(0) во нашел http://catalog.mista.ru/public/201081/ скачай. допили. делов то
   mistеr
 
54 - 22.06.18 - 10:18
(43) И где хранятся подобраные в документ, но не записанные позиции?
   kauksi
 
55 - 22.06.18 - 10:18
ну или http://catalog.mista.ru/public/194751/ для ретроградов типа Серг_1960 ))
   Куникулус
 
56 - 22.06.18 - 10:19
(0) Почему не делать документ резервирования, а потом когда уже пройдет продажа- продажу?
   LienXo
 
57 - 22.06.18 - 10:21
(56) ну почему не делать. в (36) уже предложили. Буду думать.
   LienXo
 
58 - 22.06.18 - 10:21
(53) и (55) поглядим. Делов то достаточно, но будем почитать :)
   mistеr
 
59 - 22.06.18 - 10:25
(53) Что-то там не видно временного резерва...
   Куникулус
 
60 - 22.06.18 - 10:26
(57) ТЫ написал:
> Сразу проводить документ - не комильфо, покупатель может отказаться - тогда бронь снимается.

Если будет документ резервирования/заказа, а продажа только потом, то почему бы не проводить?
   kauksi
 
61 - 22.06.18 - 10:29
(52) в ваших понятиях место - это товар? элемент номенклатуры?
не путайте место и билет. На одно место можно продать хоть 100 билетов. а оно одно
   Serg_1960
 
62 - 22.06.18 - 10:30
(55) Вах, я ретроград :) Хмм... ну да, как-то так :)

У меня РИБ на восьмерке работала по расписанию, когда этого ещё не было в типовых конфигурациях, ни РИБ, ни регламентов. А оперативным резервированием в онлайн-режиме в редактируемых документах и функционал соответствующего окружения - мало кто и сейчас этим похвастаться может.
   LienXo
 
63 - 22.06.18 - 10:31
(60) проводить основной документ не хочется. Счас начнут ворчать - но не хочется нарушать нумерацию. А вот к табличной части основного привязать документы резерва и играть с ними теоретически возможно. Поэтому как вариант отложил.
   Малыш Джон
 
64 - 22.06.18 - 10:32
(60) +1

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

К тому же сюда хорошо ложаться движения по регистру накопления. Резервирование +1, подтверждение/отказ -1.
   Малыш Джон
 
65 - 22.06.18 - 10:32
*ложатся
   gSha
 
66 - 22.06.18 - 10:35
вообще, я бы сделал независимый регистр от документа, но поддерживать его сложнеее , т.е. если ошибки в проектировании будут, то можно круто налететь .., а так вообще сейчас с документа можно писать что угодно в регистры и в любой последовательности .. просто надо понимать, нужны ли будут эти навороты ..
   Малыш Джон
 
67 - 22.06.18 - 10:38
(66) при разработке "на лету" без подробного планирования можно действительно "налететь".
Достаточно очередному падавану пропустить строчку
НаборЗаписей.Отбор.блаблабла.Установить();

и всё - регистра нет
   kauksi
 
68 - 22.06.18 - 10:38
да уймитесь вы с документом резерва. Количество всегда =1. нужно учитывать занятость позиций, ячеек склада/банка/стоянки, места театра, а не билеты. Занято/нет. а не остаток мест на складе ))
   Малыш Джон
 
69 - 22.06.18 - 10:40
(68) это сейчас оно =1, а через месяц начнется

"а вот мы тут придумали.. пусть места составные будут..."
   kauksi
 
70 - 22.06.18 - 10:40
(69) ну ... комплектация мест
   Serg_1960
 
71 - 22.06.18 - 10:41
(68) Замени слово "резервирование" на "бронирование" если не нравится. Но в типовых конфигурация чаще используются резервирование и документы резервирования, чем использование термина "бронирование" :)
   gSha
 
72 - 22.06.18 - 10:43
(67) и такое видел в своей практике .. там правда целый отдел такую строчку добавил .. правда , я после этого написал эпическое письмо на имя своего директора ..с преддожением уволить начальника айти )) правда дальше чем поржать дело не пошло, но е-ли по восстановлению было чоень много ... потерял все описание для ювелирки.. а оно там мерзкое.
   kauksi
 
73 - 22.06.18 - 10:44
(71)Хорошо. озвучу ваш бред. Ячеистый склад в ЕРП. Туда положить по одному билету. Формой выбора 10 кассиров кликая мышкой создают документ резерва, в попытке проведения которого  создается резерв, который при оплате снимается. Нравицца?
   Малыш Джон
 
74 - 22.06.18 - 10:48
(72) ну у меня такой личный опыт есть) В пору своего падаванства точно так же затёр регистр. Гребли конечно не очень много, компания очень трепетно относилась к безотказности работы, поэтому бекапились сведения каждый час. Но минут на 20 я работу всей службы доставки остановил)
   gSha
 
75 - 22.06.18 - 10:48
вы не внимательно прочитали, что написал Серг .. он блокировал какое то количество единиц, пока документ был еще не проведен, как он это делал не важно, но по сути все одно и тоже .. тут проблема лишь в том, что будеет ли вы считать то что продаете уникальным или же нет ...
у нас вот любят считать что места это конкретный объект , например кресло или квартира ..
в сапе это не так .. продается область с определенными свойствами .. т.е. если у области есть имя, то дальше когда область продемонстрировано, то идет связь с конкретным местом .. но в базах нет дури о том, что место а продано 50 раз, а записано будет, что продано, что то там .. а это что то там связано к конерктным поименнованным объектом.
   Serg_1960
 
76 - 22.06.18 - 10:50
(73) Не нравицца. Мне Ваша манера и тон не "нравицца".

А если по теме, то бронирование устанавливается на период - не успели оплатить - билет в свободном доступе.
   gSha
 
77 - 22.06.18 - 10:51
(74) а там не было бэкапов .. плюс свалили на меня .. я три или четыре дня из каких то логов восстанавливал данные (а эт овообщето сеть ювелирная была), а потом  снова поймал это место, так как потерял данные повторно .. а вот потом уже выяснил, что связка проектировщик+программист+отдел тестирования запустил такую ерунду в базу .. хотя вот я наверно при альцгеймере такое не сделаю.
   craxx
 
78 - 22.06.18 - 10:53
(0) Я когда делал свою гостиничную конфигу - регистр накопления использовал. Очень удобно с ним работать
   craxx
 
79 - 22.06.18 - 10:55
(0) если интересны подробности, велком в скайп germodachter
   LienXo
 
80 - 22.06.18 - 10:56
(78) пока собираю варианты, но за приглашение спасибо. Если припрет - загляну обязательно.
   Serg_1960
 
81 - 22.06.18 - 10:58
(Уже уходя) Некоторые зашорены до безобразия.

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

Представьте что вы на 1С реализовали морской бой и все видят эти клеточки, по которым любой может стрелять, но только один раз (в одну воронку снаряд дважды не попадает). Кстати это интересное утверждение, ибо не один снаряд дважды не стреляет :)) Расслабились? Теперь можете сообща далее писать ТЗ :)
   kauksi
 
82 - 22.06.18 - 11:05
(81) резервирование - это завершенный процесс бронирования (выбора мест). Так понятнее? Если в терминах морсокго боя - то место куда уже попал снаряд. А бронирование - это выбор куда стрельнуть, чтобы не попадать два раза...
   Малыш Джон
 
83 - 22.06.18 - 11:32
(81) +1

программировать надо начинать не в 1С, а сначала весь процесс продумать и в проектировщике(ну или на бумаге) схему процесса нарисовать
   Малыш Джон
 
84 - 22.06.18 - 11:33
(82) :) наверное имел в виду "резервирование - это результат процесса бронирования"))
   Адинэснег
 
85 - 22.06.18 - 11:41
(0) ну без блокировок все равно не взлетит
я бы сделал бронирование при оформлении заказа до 10 минут
неперешедшие брони в состояние заказа аннулирует Фоновое задание
   Адинэснег
 
86 - 22.06.18 - 11:46
перед оформлением заказа проверять, не сняло ли ФЗ твою бронь... делать на РН, заблокировал, провёл, проверил остаток, ушел в минус - отказ транзакции, в ноль - ок.
   1sanekmaloi1
 
87 - 22.06.18 - 13:03
(86)кто в этот РН будет писать? Открыт новый док, не записан не проведен, открывается форма подбора и клацается на Номенклатура1 в эту секунду для всех остальных должно появится отказ при дабл клике на N-минут/
   Cyberhawk
 
88 - 22.06.18 - 14:01
(84) Нет, процесс бронирования не обязательно завершается резервированием
   Cyberhawk
 
89 - 22.06.18 - 14:02
(87) Пусть пишут в независимый РС "Блокировки номенклатуры"
   1sanekmaloi1
 
90 - 22.06.18 - 14:21
(89)Я не против.
   Serg_1960
 
91 - 22.06.18 - 17:11
Хех. Привыкли все работать по предоплате и перестали понимать, что бронирование - это резервирование без оплаты(до оплаты).
   Garykom
 
92 - 22.06.18 - 17:22
(0) Если товар уникальный (кол-во везде 1) то банально реквизит в справочник товаров с выбором оператора, который забронировал.
   gSha
 
93 - 22.06.18 - 17:26
ну для билетов это не катит, там ведь зал один, а сеансов много . Т.е. там уже какая то составная ерунда появляется. Типа время, номер сеанса, номер кресла.
   Garykom
 
94 - 22.06.18 - 17:38
(93) Эта составная ерунда прекрасно влезает в один товар
   lodger
 
95 - 22.06.18 - 17:40
(94) ага, особенно круто при этом вести ценообразование, ведь на одно время, номер сеанса и номер кресла может быть назначен один или другой фильм с разными ценами.
   Garykom
 
96 - 22.06.18 - 17:45
(95) Не тупи, Товар = фильм, зал, дата, время (сеанс) + № кресла
   runoff_runoff
 
97 - 22.06.18 - 17:46
документ может быть не проведен, но иметь движения, если что
   Garykom
 
98 - 22.06.18 - 17:47
(96)+ Этот товар называется "Билет", который уникально определяет все прочие реквизиты "куда и за что"
   lodger
 
99 - 22.06.18 - 17:51
(96) ага, а потом жаба не задавит содержать справочник номенклатуры растущий со скоростью около 45000 элементов в сутки (это для кинотеатра где около 4500 кресел и около 10 сеансов за день).
   Garykom
 
100 - 22.06.18 - 17:56
(99) Какая нафик разница что растет справочник или регистр?

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

  1  2   

Список тем форума
Рекламное место пустует Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Рекламное место пустует