Имя: Пароль:
1C
1С v8
Проектирование периодических структур данных
0 patria0muerte
 
25.03.15
09:31
День добрый, Коллеги!

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

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

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

Кто что подскажет?
1 PLUT
 
25.03.15
09:34
подсмотреть, как эта содомия сделана в отраслевых "1СБардель" и скопи3.14дить оттуда?
2 Остап Сулейманович
 
25.03.15
09:40
(0) "В ЗУПе же вроде с отпусками подобная штука?"
Точно так. Особенно с больничными. Когда человек сначала не выходит на работу, потом приносит больничный на один период, потом ему этот же больничный продлевают и т. д.

Вообще регистры расчета предназначены не "исключительно для" расчета зарплаты. И основная их фишка - период действия. И для бронирования ИМХО - самое то.
3 patria0muerte
 
25.03.15
09:44
(2) Вот думал насчет них. Но блин в этих РР я дуб дубом. Сколько курсов не смотрел, плохо они мне даются, ой плохо...

(1) Таки вот к отраслевкам доступа нет. Валяется под рукой КИНТ:УправлениеСанаторием, но там внутрях такой трэш, что и с поллитрой не разобрать. Там все реализовано на РБ, и не особо мне такой подход понравился.
4 D_E_S_131
 
25.03.15
09:46
Периодический регистр сведений с измерением "Номер" и ресурсами "ДатаНачалаБрони", "ДатаОкончанияБрони". Если нужно четко фиксировать изменение состояния брони, то сделать подчиненным документу "УстановкаСнятиеБрони" и формировать записи при проведении. Нафига все усложнять-то?
5 patria0muerte
 
25.03.15
09:47
Вопрос то собственно не в том, как реализовать. А что почитать по данной теме, чтобы самому уже вкурить как и что делать. Сейчас заканчиваю основной блок, но чую, что куда то не туда свернул.
6 patria0muerte
 
25.03.15
09:52
(4) Были мысли. Но контроль заполненности не красиво выходит. Да и при данной реализации нужно доки задним числом править при изменении срока бронирования, что не есть хорошо.

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

Есть РН "ЗанятостьНомеров" который в разрезе Гостиниц, Номеров, ФизическихЛиц и ЗаявокНаПоселение (документ, агрегирующий всю информацию по поселению, суммы, прочую инфу) хранит данные о занятости. Ресурс один: "Количество"
При бронировании создаются две записи: +1 количество по набору измерений на дату начала и -1 по тому же набору на дату окончания. Перенос брони и прочие операции сторнируют записи по одному номеру гостиницы и пишут их на другой. Вот такая свистопляска.
7 ShoGUN
 
25.03.15
09:57
(4) В теории неплохо, на практике, как человек, ковырявший табель в ЗУПе, могу сказать, что работает это так себе. Логику периода действия надо закладывать в объектах хранения, а не эмулировать при считывании данных. Я за регистр расчёта, но разобраться там всё же придётся. За отправную точку взять типовой ЗУП и посмотреть, как там делаются перерасчеты.
8 Лефмихалыч
 
25.03.15
09:59
(0) регистры расчета для этого предназначены, т.к. только в них есть вытеснение и пристёгивание суммы к периоду (к тому. который с..по, а не просто дата)
9 1с80
 
25.03.15
10:00
(4) Только зачем в ресурсах даты? Ресурсом будет статус - есть бронь/нет брони. А датами начала и окончания брони будет период записи регистра.
(6) А в чем проблема с контролем заполненности? Вроде бы срез на дату все покажет.
10 rphosts
 
25.03.15
10:03
(0) Вытесняющие друг друга ВР, не?
11 D_E_S_131
 
25.03.15
10:04
(6) Не понял твоих сомнений.
(7)(8) И как связаны "бронирование номера" с суммами и "вытеснением"?
(9) Даты что бы знать с какого по какое номер забронирован. Отсутствие брони это по "дыре" в датах определяется.
12 patria0muerte
 
25.03.15
10:08
(11) Не, (9) вроде дело говорит. Имеется ввиду 2 записи, типа
21.03 Номер 1 Забронирован
25.04 Номер 1 Свободен

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

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

А РР надо подробнее раскурить. Кстати, у Чистова Павла же где-то был небольшой курс о Расчетных механизмах безотносительно расчета ЗП, не?
13 stix2010
 
25.03.15
10:09
А что обычных регистров накопления не хватит? А 1С:Бардель, та еще конфа, одни LOLы можно собирать
14 Лефмихалыч
 
25.03.15
10:11
(11) бронирование - это я плачу Х бабла ЗА ПЕРИОД с...по. Всякие допуслуги, досрочные и прочие изменения - это перерасчет.
Вообще, те, кто пробовал реализовать аренду чего-либо сначала без регистров расчета, а потом - с, меня поймут
15 patria0muerte
 
25.03.15
10:12
(11) Сомнения в том, что в твоем случае очень неудобно историю по всем этим периодам собирать. Т.к. при переносе брони или оперативном переселении человека у тебя будет новая запись актуальная с другим номером. В итоге две актуальные записи - на два разных номера. Ну и далее там нюансов хватает, пробовал так сделать (собственно первое, что на ум пришло)
16 1с80
 
25.03.15
10:13
(12) В (11) тоже здравая мысль, чтобы дату окончания брони хранить в самой записи. Так будет проще отчет с информацией об окончании брони делать, который скорее всего понадобится.

Делал когда то аналогичную задачу. Точно помню что остановился на регистре сведений, но деталей реализации уже не помню. Регистр расчетов тоже рассматривал, как наиболее подходящий на первый взгляд. Но в итоге от него отказался из-за ненужных дополнительных заморочек. Он все-таки на конкретную задачу расчета зарплаты рассчитан.
17 D_E_S_131
 
25.03.15
10:13
(12) Вопрос в том что и когда будет формировать записи РС. Если проводишь документ и получаешь одну запись:
"Номер 1" - 21.03 - 25.04, а не две.

(14) Аргумент. Но про суммы речи не шло.
18 patria0muerte
 
25.03.15
10:15
(14) За аналогию с арендой - огромное вам мерси. В этом свете не смотрел еще на задачу.
19 D_E_S_131
 
25.03.15
10:17
(15) Ты упорно игнорируешь "срез последних". Уникальность измерения "Номер" даст всегда актуальную информацию.
20 patria0muerte
 
25.03.15
10:18
Еще кстати бонусом такая штука, что некоторые проживающие (работники предприятия) могут селиться на неопределенный срок (т.е. пока не уволятся, т.н. "постоянное проживание").
В данном случае даты окончания впринципе нет.
21 patria0muerte
 
25.03.15
10:21
(19) Да, в (15) был не совсем прав. Понял, что ты имеешь ввиду.
22 Лефмихалыч
 
25.03.15
10:22
(15) это все перерасчет.
Я не говорю, что регистры сведений не нужны совсем. Нужны, но просто они должны быть эдакими "итогами" - то есть хранить избыточную информацию для удобства оперативной работы. Подобно регистру СвободныеОстатки, который в пару к партионному добавляют, чтобы в каждой расходной себест не считать
23 МихаилМ
 
25.03.15
10:22
коли речь о проектировании
то

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

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


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

типа час, день, месяц, либо признак активности
24 patria0muerte
 
25.03.15
10:27
(22) А как с арендой определял, что объект аренды занят?  Т.е. например кто-то взял машину на год и она должна числиться как занятая все это время. По РР? Или РС использовал со статусами типа как (4) или (9)
25 patria0muerte
 
25.03.15
10:29
(14) Как бы суммы то особой роли не играют пока что. Я обхожусь простым РН оборотным на данный момент. Больше волнует контроль занятости на период действия.
26 Лефмихалыч
 
25.03.15
10:31
(25) тогда тупой периодический РС со статусом. Только каким-то образом (например регзаданием) надо гарантировать, что в момент окончания пеирода действия в этот РС будет складываться запись "Свободен"
27 1с80
 
25.03.15
10:35
(25) Как вариант, можно даже не периодический РС использовать, а обычный. С измерениями дата и номер и ресурсом статус. При бронировании номера делаются записи со статусом Бронь на каждую дату.
28 patria0muerte
 
25.03.15
10:36
(27) Как то сильно жирно прям, на каждый день записи пихать. ))
29 1с80
 
25.03.15
10:40
(28) Зато теоретически должно быстрее работать без среза последних. Хотя думаю для данной задачи разница будет не критичной.
30 asdfg13
 
25.03.15
10:51
(27) + к этому РС с историей изменений
31 Лефмихалыч
 
25.03.15
12:58
(28) зачем на каждый день? Где ты видишь на каждый день?
Одна запись на начало, другая - на конец.
Их не вариант сразу писать потому, что клиент же и продлить может, а тогда надо будет что-то предпринимать.
32 asdfg13
 
25.03.15
13:13
(31) Почему не на каждый день? Так же удобнее. Продлил бронь - дополнительные записи и все. Снял бронь - меняем статус. Никакого гемороя с периодами С-ПО.
33 Лефмихалыч
 
25.03.15
13:17
(32) да давай уже каждую мину, чо там мелочиться-то?
А когда период поменяется в течение срока действия договора, будем танцы с бубном плясать по удалению ненужных записей и замене на нужные.
34 asdfg13
 
25.03.15
13:27
вообще бы на целый год вперед завел бы по каждому номеру и дате со статусом "Без брони". Потом только статус меняй и все, никаких плясок.
35 asdfg13
 
25.03.15
13:28
1000 номеров 365 дней = 365000 записей за год. Не вопрос.
36 D_E_S_131
 
25.03.15
13:45
(24) "А как с арендой определял, что объект аренды занят?"
Элементарно срез последних и получение значения ДатаОкончанияБрони по нужному Номеру. Если дата меньше чем текущая, то свободен. В случае проверки свободности в интервале проверяешь 2 даты. Только и всего.