Коллеги, нужно авторитетное мнение, как правильно организовать данные.

Пишем конфу по учету ж.д. вагонов на территории предприятия. Жизненный цикл «вагона» такой: прибывает на территория, катается по путям на территории, убывает с территории. Практически на каждом вагоне установлены от одного до нескольких десятков запорном-пломбировочных устройств (далее ЗПУ). Каждое ЗПУ характеризуется видом  и номером. Когда вагоны прибывает на нем установлены некий набор ЗПУ, в процессе того как он (вагон) «шарахается» по территории эти ЗПУ снимают и устанавливают другие. Вопрос в том, как правильно организовать хранение данных истории снятия/установки ЗПУ.

Если проще, то вопрос сводится к тому, как правильно организовать хранение периодической табличной части?

ну, очевидно же - через периодический РС.

Это понятно, что через РС. Вопрос в том как правильно организовать этот РС.

Мне видится два варианта:

1. Периодический регистр сведений
Измерения:
Вагон – справочник вагонов
Вид ЗПУ – справочник видов ЗПУ
Номер ЗПУ – строка
Ресурсы:
Установлено – Булево

2. Периодический регистр сведений + Воспитательный справочник с таб. частью
Измерения:
Вагон – справочник вагонов
Ресурсы:
УстновленныеЗПУ – СправочникСсылка.УстановленныеЗПУ

Во вспомогательном справочнике заполнять табличную часть:
Вид ЗПУ – справочник видов ЗПУ
Номер ЗПУ – строка

Если реализовывать первый вариант, то документ, с помощью которого регистрируется факт установки ЗПУ, должен будет «отменять» движения предыдущего документа и добавлять свои движения. Как мне кажется отмена «не своих» движений не совсем верный подход.

(2) "Воспитательный справочник" - в мемориз)

Да! Только сейчас заметил.
Надеюсь поднял настроение :-)

(3) Имелось в виду "вспомогательный"

Табличная часть у документа должна быть обычная. На каждое прибытие убытие и "шараханье" вагона создавать отдельный документ с перечислением "ЗПУ" в табличной части. При проведении писать в регистр сведений.

(6) Совершенно с Вам согласен. Вопрос в том как правильно организовать регистр сведений. Что в измерения, что в ресурсы?

(7) Выкладывай свои варианты, остальные - подхватят

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

(2) грубейшая ошибка. Такая архитектура приведет к тому, что один и тот  же номер ЗПУ будет одновременно иметь несолкьо видов и одновременно будет установлен на разные вагоны

+(10) ну, или, другое следствие - объекта ЗПУ в системе нет. есть отдельно виды, отдельно номера и отдельно вагоны, которые в какое-то единое аналитическое целое не собираются ни когда

+(10) речь про первый вариант.

Второй вариант учитывает не ЗПУ, а вагоны, что противоречит задаче.

(9) Дело в том что ЗПУ это такое устройство, которое выкидывают после снятия. Причем выкидывают физически. Соответственно, если делать справочник "ЗПУ", то со временем там будет куча записей, которые будут использоваться только один раз. Это, в каком то роде, похоже на паспорт у физ. лица. Только у физ. лица не может быть несколько паспортов, а у вагона может быть несколько одинаковых видов ЗПУ, но с разными номерам.

(8) Я в (2) предложил свои варианты

(14) во втором варианте таб часть не нужна

(14) Да, извини.

проще 1 измерение вагон и 2 ресурса
видЗпу - справочник
НомерЗпу - строка/число
усё.

(13) что мешает их через время регламентным заданием удалять, если они не нужны?

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

(17) На одном вагоне в один и тот же период времени может быть установлено несколько ЗПУ. Соответственно набор измерений "Период, Вагон" не прокатят, т.к. записи для двух и более ЗПУ не будут уникальны.

(18) А в регистре при этом оставлять битую ссылку? Нееее... Это не наш метод :-)

(20) ну тогда ресурс установлено - булево и реквизит регистра НомерЗПУ

С таб частью у тебя будет геммор, если на вагоне меняют одну пломбу, а не все.

Судя по всему первый вариант все-таки более правильный. Только в документе установки ЗПУ нужно будет делать две таб. части: ЗПУ, которые снимаем и ЗПУ, которые устанавливаем.

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

(21) она самоубьется, если измерение ведущее

Яб сделал через регистр накопления. Справочник вагонов, и два регистра - Вагоны (измерения Вагон и МестоНахождения) и ЗПУ (Измерения Вагон, НомерЗПУ). Ну и соответственно документы по приходу, расходу и перемещению вагонов и по приходу и расходу ЗПУ. По остаткам и движениям регистров видно наичие вагонов и ЗПУ на вагонах и их движение. Как то так.

Кстати, автор, а какова цель автоматизации-то?
Какую информацию заказчик хочет из системы потом получать?

(27) Ну, если я правильно понял (0), то "организовать хранение данных истории снятия/установки ЗПУ."

(28) без ответа на вопрос: "Для чего это организовывать", об архитектуре рано говорить.

(0) Автор, у тебя там как - ТЗ есть? Или разработка из серии "сначала внедрим, потом разберемся для чего"? :)

+1 за регистр накопления

(30) Это называется Agile )))

(27) Заказчик хочет получить всю информацию по вагону на произвольный момент времени.

(30) К большому сожалению ТЗ нет. Я и чтец и жнец и на дуде игрец. Т.е. есть в общем виде сформулированная задача (см. (33) ) я сам проектирую структуру данных и сам же ее программирую.

(33) все, ничего, много, мало и т.д. - это слова без смысла

На одной из фирм допиливал решение похожей задачи для УПП. Учет прохождения этапов выполнения техопераций из спецификаций. Два документа "Паспорт"(на серию продукции) и "Операция паспорт"(один шаг выполнения). Регистры сведений  "Технологические операции"(первоначальные), "Технологические операции выполненные", _"Состояние паспорта". Остаточный регистр накоплений "Остатки по паспортам"

(36) Если честно, не врубился... Какие ресурсы/измерения у регистров. Какие движения какой документ делает?

(35) Ок. Исправляюсь...
Здесь (33) имелось в виду чтобы на любой момент времени можно было узнать где находился вагон, зачем он там находился и какие ЗПУ на нем были установлены.

(0) ТС у тебя есть всего 2 вида/типа ШК.

ШК вагона и ШК ЗПУ вот это и храни:
датавремя|операция (установка или снятие)|ШК вагона 1|ШК ЗПУ 1
датавремя|снятие|ШК вагона 1|ШК ЗПУ 2
...

(39) Что такое ШК?

Вагонов сколько в месяц приходит - уходит - катается?

Можешь  с  типового зупа содрать решение

вагон =  организация
ЗПУ = сотрудник

С периодическим регистром вроде все хорошо, но мне не дает покоя вот такая ситуация:

Вагон прибывает 24.10.2016. На нем установлено два ЗПУ. Документа сделает запись в регистре:
Вагон1, ВидЗПУ, №1, Установлено = Истина
Вагон1, ВидЗПУ, №2, Установлено = Истина

Некий пользователь указал, что 27.10.2016 на нем установили одно ЗПУ. Документа сделает запись в регистре:
Вагон1, ВидЗПУ, №1, Установлено = Ложь
Вагон1, ВидЗПУ, №2, Установлено = Ложь
Вагон1, ВидЗПУ, №3, Установлено = Истина

А потом другой (или тот же) пользователь указал, что 25.10.2016 на нем установили три ЗПУ. Документа сделает запись в регистре, соответствующую состоянию на момент проведения:
Вагон1, ВидЗПУ, №1, Установлено = Ложь
Вагон1, ВидЗПУ, №2, Установлено = Ложь
Вагон1, ВидЗПУ, №А, Установлено = Истина
Вагон1, ВидЗПУ, №Б, Установлено = Истина
Вагон1, ВидЗПУ, №В, Установлено = Истина

В результате срез последних с пустой датой нам даст, что на этом вагоне установлено четыре ЗУП:
№3, №А, №Б и №В. Хотя на самом деле, на нем установлена только одно ЗПУ: №3.

(42) А где отражение снятие ЗПУ?

(40) Ыыы не знать кто когда и главное зачем придумал штрих коды... Это 5 ))

http://shtrih-center.ru/state/istotia_shtix.html

(43) Мне уже стало боязно за внедрение 1С в РЖД...

(44) Просто сокращения не расшифровал... Только все-таки я не понял какое отношение штрих-код имеет к моей задаче.

На каждый вагон лепится ШК. На каждое ЗПУ так же лепится ШК.
Далее ТСД и легкость фиксирования установки/снятия ЗПУ в вагонах.

А как хранить в базе все это дело уже глубоко фиолетово.

(47) Вопрос как раз в том как правильно хранить это в базе.

(43) Собственно установка измерения "Установлено" в значение "Ложь" как раз отражает снятие ЗПУ с вагона.

(47)+ Сча есть недорогие RFID метки и сразу пломбы с метками внутри, это еще удобнее. http://www.isbc-rfid.ru/applications/logistics/

(49) Словишь глюки когда несколько раз установили/сняли одно ЗПУ в разное время (в регистре что будет?)

(48) если  количество  вагонов меряется сотнями или  тысячами в  год, то  как хранить в  базе действительно  фиолетово.

вернее определяется желанием \ умением \ предпочтением разработчика.

самое  тупое решение
справочник  вагонов, справочник ЗПУ, справочник  водов  ЗПУ привязанный к справочнику ЗПУ .
Регистр накопления с измерениями вагон, ЗПУ, движениями + и  -.
Два документа установить ЗПУ, снять ЗПУ.

(50) Повторюсь, вопрос не в том как облегчить ввод данных пользователю а как хранить данные чтобы на произвольный момент времени можно было получить данные на каком вагоне какие ЗПУ установлены.

(54) Перефразируй не "на каком вагоне какие ЗПУ установлены", а более правильно "Какое ЗПУ в каком вагоне установлено".

И приходим к регистру сведений где ЗПУ это измерение, а вагон это ресурс

(54) " Повторюсь, вопрос не в том как облегчить ввод данных пользователю" на  самом  деле этот вопрос ключевой.

т.к. от правильности внесенных номеров  ЗПУ будет  зависеть корректность учета.

И если эти новера будут вносить рабочие устанавливающие \снимающие ЗПУ, то будет огромное количество ошибок. формулиовка от начальства - "Ваша система не работает"

(55) Я правильно понимаю, что в таком случае при снятии ЗПУ с вагона нужно будет делать движение, где ЗПУ заполнено, а вагон пустая ссылка?

(56) Согласен, что это вопрос важный и интересный, но это другой вопрос - как организовать ввод данных. Пока я предполагаю что данные вводятся вручную. Предлагаю исходить из этого.

(58) эээ....

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

(57) Угу или заведи специальный один "общий вагон" для снятых ЗПУ. Точнее лучше уточни куда деваются снятые и как хранятся.

Возможно учет ЗПУ тоже нужен с приобретением/постановкой на учет и использованием/установкой в вагоны и дальнейшим снятием (одноразовые или многоразовые они?)

(60) Они (ЗПУ) снимаются и утилизируются. Соответственно одноразовые.

(61) ну предопределенное значение в справочник вагонов можно
Тогда и стата по утилизированным на дату заодно

Если кому интересно, то на другом форуме предложили вот такое решение:

Вагоны. Справочник.
ВидЗПУ. Справочник или перечисление. Вам лучше знать.
ЗПУ. Справочник. Реквизиты "ВидЗПУ" и "НомерЗПУ".
Документ.УстановкаЗПУ: Вагон - реквизит шапки(Справочник.Вагоны). ТабЧать: Реквизит "ЗПУ" -ссылка на справочник.ЗПУ
Периодический РС "УстановкаЗПУ", Регистратор: "Документ.УстановкаЗПУ". Измерение: "Вагон".
В принципе, этого достаточно для определения, какие ЗПУ, когда и на какой вагон были установлены.
Если же у Вас есть "таракан", внедренный от 1с, что отчёты нужно формировать только из регистров, тогда требуется ещё
один независимый непериодический регистр сведений с измерениями:
"Вагон", "ЗПУ", "УстановкаЗПУ"

(36) Коллега, если не трудно поясните суть задачи, которая у Вас была и как вы её решали.

(63) и смех и грех. Регистр бессмысленный. Любые отчеты про ЗПУ будут строиться по документам. КГ/АМ.
Измерением должно быть ЗПУ, а вагон - ресурсом. Тогда в регистре будет храниться инфа "на какой вагон установлено это ЗПУ".

>Если же у Вас есть "таракан", внедренный от 1с, что отчёты нужно формировать только из регистров

http://s00.yaplakal.com/pics/pics_original/2/2/0/1905022.jpg

(65) Оно как бы "да": измерение - ЗПУ, ресурс - Вагон. Но тогда придется еще и отслеживать последовательность, чтобы не получить ситуацию, которую я описывал в (42). А подход с двумя регистрами такую проблему решает.

(67) перед проведением надо проверять проверки, чтобы таких шаманов ловить на взлёте