День добрый, Коллеги!

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

В данный момент реализую несложную конфигурацию для целей гостиничного учета. И работа тут ведется с периодами, т.е. бронирование с даты1 по дату2, перетаскивание данной брони с номера внутри периода, продлевание бронирования, внезапное выселение с послежующим снятием брони и прочий адЪ и содомия.

Собственно хотел бы узнать у нашего доблестного коммьюнити, есть где чего почитать по проектированию таких систем? Кто то вещал мне, что есть на ИТС годная статья, но не нашел таковой. Или может где в типовых конфах есть примеры реализации подобных структур? Или где в ЖКК сокровенные знания ютятся?
В ЗУПе же вроде с отпусками подобная штука? Или нет?

Кто что подскажет?

подсмотреть, как эта содомия сделана в отраслевых "1СБардель" и скопи3.14дить оттуда?

(0) "В ЗУПе же вроде с отпусками подобная штука?"
Точно так. Особенно с больничными. Когда человек сначала не выходит на работу, потом приносит больничный на один период, потом ему этот же больничный продлевают и т. д.

Вообще регистры расчета предназначены не "исключительно для" расчета зарплаты. И основная их фишка - период действия. И для бронирования ИМХО - самое то.

(2) Вот думал насчет них. Но блин в этих РР я дуб дубом. Сколько курсов не смотрел, плохо они мне даются, ой плохо...

(1) Таки вот к отраслевкам доступа нет. Валяется под рукой КИНТ:УправлениеСанаторием, но там внутрях такой трэш, что и с поллитрой не разобрать. Там все реализовано на РБ, и не особо мне такой подход понравился.

Периодический регистр сведений с измерением "Номер" и ресурсами "ДатаНачалаБрони", "ДатаОкончанияБрони". Если нужно четко фиксировать изменение состояния брони, то сделать подчиненным документу "УстановкаСнятиеБрони" и формировать записи при проведении. Нафига все усложнять-то?

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

(4) Были мысли. Но контроль заполненности не красиво выходит. Да и при данной реализации нужно доки задним числом править при изменении срока бронирования, что не есть хорошо.

Сейчас сделано как:

Есть РН "ЗанятостьНомеров" который в разрезе Гостиниц, Номеров, ФизическихЛиц и ЗаявокНаПоселение (документ, агрегирующий всю информацию по поселению, суммы, прочую инфу) хранит данные о занятости. Ресурс один: "Количество"
При бронировании создаются две записи: +1 количество по набору измерений на дату начала и -1 по тому же набору на дату окончания. Перенос брони и прочие операции сторнируют записи по одному номеру гостиницы и пишут их на другой. Вот такая свистопляска.

(4) В теории неплохо, на практике, как человек, ковырявший табель в ЗУПе, могу сказать, что работает это так себе. Логику периода действия надо закладывать в объектах хранения, а не эмулировать при считывании данных. Я за регистр расчёта, но разобраться там всё же придётся. За отправную точку взять типовой ЗУП и посмотреть, как там делаются перерасчеты.

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

(4) Только зачем в ресурсах даты? Ресурсом будет статус - есть бронь/нет брони. А датами начала и окончания брони будет период записи регистра.
(6) А в чем проблема с контролем заполненности? Вроде бы срез на дату все покажет.

(0) Вытесняющие друг друга ВР, не?

(6) Не понял твоих сомнений.
(7)(8) И как связаны "бронирование номера" с суммами и "вытеснением"?
(9) Даты что бы знать с какого по какое номер забронирован. Отсутствие брони это по "дыре" в датах определяется.

(11) Не, (9) вроде дело говорит. Имеется ввиду 2 записи, типа
21.03 Номер 1 Забронирован
25.04 Номер 1 Свободен

если я правильно понял.

Подумаю над этим вариантом.

А РР надо подробнее раскурить. Кстати, у Чистова Павла же где-то был небольшой курс о Расчетных механизмах безотносительно расчета ЗП, не?

А что обычных регистров накопления не хватит? А 1С:Бардель, та еще конфа, одни LOLы можно собирать

(11) бронирование - это я плачу Х бабла ЗА ПЕРИОД с...по. Всякие допуслуги, досрочные и прочие изменения - это перерасчет.
Вообще, те, кто пробовал реализовать аренду чего-либо сначала без регистров расчета, а потом - с, меня поймут

(11) Сомнения в том, что в твоем случае очень неудобно историю по всем этим периодам собирать. Т.к. при переносе брони или оперативном переселении человека у тебя будет новая запись актуальная с другим номером. В итоге две актуальные записи - на два разных номера. Ну и далее там нюансов хватает, пробовал так сделать (собственно первое, что на ум пришло)

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

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

(12) Вопрос в том что и когда будет формировать записи РС. Если проводишь документ и получаешь одну запись:
"Номер 1" - 21.03 - 25.04, а не две.

(14) Аргумент. Но про суммы речи не шло.

(14) За аналогию с арендой - огромное вам мерси. В этом свете не смотрел еще на задачу.

(15) Ты упорно игнорируешь "срез последних". Уникальность измерения "Номер" даст всегда актуальную информацию.

Еще кстати бонусом такая штука, что некоторые проживающие (работники предприятия) могут селиться на неопределенный срок (т.е. пока не уволятся, т.н. "постоянное проживание").
В данном случае даты окончания впринципе нет.

(19) Да, в (15) был не совсем прав. Понял, что ты имеешь ввиду.

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

коли речь о проектировании
то

по интервалу невозможно построить эффективного индекса .
соответственно fullscan гарантирован.

и при количестве записей более 100 000 многопользовательская
работа будет не комфортной.


соответственно желательно включать поля уточнения (в индексы)

типа час, день, месяц, либо признак активности

(22) А как с арендой определял, что объект аренды занят?  Т.е. например кто-то взял машину на год и она должна числиться как занятая все это время. По РР? Или РС использовал со статусами типа как (4) или (9)

(14) Как бы суммы то особой роли не играют пока что. Я обхожусь простым РН оборотным на данный момент. Больше волнует контроль занятости на период действия.

(25) тогда тупой периодический РС со статусом. Только каким-то образом (например регзаданием) надо гарантировать, что в момент окончания пеирода действия в этот РС будет складываться запись "Свободен"

(25) Как вариант, можно даже не периодический РС использовать, а обычный. С измерениями дата и номер и ресурсом статус. При бронировании номера делаются записи со статусом Бронь на каждую дату.

(27) Как то сильно жирно прям, на каждый день записи пихать. ))

(28) Зато теоретически должно быстрее работать без среза последних. Хотя думаю для данной задачи разница будет не критичной.

(27) + к этому РС с историей изменений

(28) зачем на каждый день? Где ты видишь на каждый день?
Одна запись на начало, другая - на конец.
Их не вариант сразу писать потому, что клиент же и продлить может, а тогда надо будет что-то предпринимать.

(31) Почему не на каждый день? Так же удобнее. Продлил бронь - дополнительные записи и все. Снял бронь - меняем статус. Никакого гемороя с периодами С-ПО.

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

вообще бы на целый год вперед завел бы по каждому номеру и дате со статусом "Без брони". Потом только статус меняй и все, никаких плясок.

1000 номеров 365 дней = 365000 записей за год. Не вопрос.

(24) "А как с арендой определял, что объект аренды занят?"
Элементарно срез последних и получение значения ДатаОкончанияБрони по нужному Номеру. Если дата меньше чем текущая, то свободен. В случае проверки свободности в интервале проверяешь 2 даты. Только и всего.