Как сделать сотрудникам детей

28.10.21

Задачи пользователя - Адаптация типовых решений

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

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

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

 

Вариант 1: Справочник Сотрудники с табличной частью

 

 

Вариант 2: Справочник Сотрудники2 и регистр сведений Дети с ведущим измерением Сотрудник

 

 

1. Удобство ввода

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

 

 

против

 

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

&НаСервере
Процедура ПриЧтенииНаСервере(ТекущийОбъект)
	Набор = РегистрыСведений.Дети.СоздатьНаборЗаписей();
	Набор.Отбор.Сотрудник.Установить(Объект.Ссылка);
	Набор.Прочитать();	
	ТаблицаДети.Загрузить(Набор.Выгрузить());
КонецПроцедуры
&НаСервере
Процедура ПриЗаписиНаСервере(Отказ, ТекущийОбъект, ПараметрыЗаписи)
	Набор = РегистрыСведений.Дети.СоздатьНаборЗаписей();
	Набор.Отбор.Сотрудник.Установить(ТекущийОбъект.Ссылка);
	Набор.Загрузить(ТаблицаДети.Выгрузить());
	Для каждого Запись Из Набор Цикл   
		Запись.Сотрудник = ТекущийОбъект.Ссылка;
	КонецЦикла; 	
	Набор.Записать();
КонецПроцедуры

Обратите внимание: необходимо использовать именно ПриЧтенииНаСервере и ПриЗаписиНаСервере, а не ПриСозданииНаСервереПередЗаписьюНаСервере или ПослеЗаписиНаСервере.

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

Таким образом второй вариант у нас разделился на два: 2а - с редактированием записей регистра и 2б - с редактированием в таблице формы и сохранением набора записей.

2. Отмена изменений 

Предположим, что пользователь, изменив какой-нибудь элемент справочника, хочет закрыть его, не сохраняя данные. Очевидно, что в варианте 1 и 2б это возможно, а в варианте 2а - нет. Также при создании нового элемента в варианте 2а невозможно добавить детей, не сохранив самого сотрудника. Эти два случая могут вызвать у неопытного пользователя вопросы и, возможно, привести к ошибкам.

3. Объектные блокировки

Платформа содержит неплохой механизм объектных блокировок, не позволяющий одновременного редактирования объектов. В нашем случае для варианта 1 все хорошо - два пользователя не могут одновременно редактировать список детей, в варианте 2а - список изменять могут, не могут только одновременно редактировать одну строку, в варианте 2б все печально - во время редактирования таблицы с детьми, другой пользователь или процесс может изменить этот список, и при окончании редактирования все изменения другого пользователя пропадут. Что тут можно сделать? ЗаблокироватьДанныеДляРедактирования здесь не поможет, единственный вариант - запоминать первоначальный набор записей и проверять его перед записью (конечно, проверка и запись нового набора должна сопровождаться управляемой блокировкой).

4. Создание копированием

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

5. Отборы в списке

Здесь все просто: в первом варианте отбор по табличной части работает "из коробки":

 

 

Во втором варианте это так не работает. Вообще.

6. История изменений

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

 

 

А вот с регистрами все по-другому.

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

 

 

 

В варианте 2б немного иначе. В нем мы записываем записи набором. Здесь платформа понимает, что в каких-то записях набора мы можем изменить ресурс или реквизит, и правильно указывает флаг изменения. Но изменение одного из измерений платформа также считает удалением/добавлением:

 

 

7. Регистрация факта изменений

Этот пункт напрямую связан с предыдущим. Если мы захотим сделать свою регистрацию изменений, например для того, чтобы сохранять версии, или для отслеживания "дельты" при изменениях каких-либо данных (конечно же, речь сейчас не о детях), или для подсчета объема сделанной работы, то в случаях с регистром сведений это сделать в полном объеме либо вообще нельзя (если у нас происходят изменения посредством менеджера), либо достаточно трудоемко. Ведь теоретически запись регистра может осуществляться с разными по составу отборами. Для табличных частей определение факта изменения и содержание этого изменения гораздо проще.

8. Общие реквизиты

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

9. Получение объекта

Цитата с ИТС: "При чтении отдельных реквизитов объекта из базы данных следует иметь в виду, что вызов метода ПолучитьОбъект или обращение к реквизитам объекта через точку от ссылки приводит к загрузке объекта из базы целиком, вместе с его табличными частями." Если табличных частей несколько и/или они объемные по количеству строк или колонок, то это может отрицательно сказаться на производительности. В таком случае вынос табличной части в регистр может дать положительный эффект, особенно если данные табличной части используются достаточно редко.

10. Права доступа

Тут все очевидно: для первого варианта доступ к сотруднику и его детям определяются одними и теми же ролями, для второго - могут быть разные роли. Это может иметь смысл, когда разные пользователи имеют разные уровни доступа. При отсутствии прав на доступ к данным о детях вариант 2а будет работать автоматически, в варианте 2б в коде надо дописать необходимые проверки.

11. Удаление

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

12. Порядок работы с данными

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

13. Данные табличных частей всегда записываются вместе с объектом, в отличие от записей регистра. Это плохо.

Иногда данные табличных частей могут часто и/или интенсивно меняться. Чтобы не перезаписывать каждый раз объект (а при этом тратится время на выполнение обработчиков записи), лучше использовать отдельный регистр.

14. Данные табличных частей всегда записываются вместе с объектом, в отличие от записей регистра. Это хорошо.

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

15. Удаление записей регистра

Нельзя забывать что записи регистра записываются и удаляются наборами. Нужно быть вдвойне осторожным, чтобы при записи пустого набора не забыть и не перепутать элементы отбора. Чтобы создать себе проблему достаточно одной строки  РегистрыСведений.Дети.СоздатьНаборЗаписей().Записать(); Испортить содержимое табличных частей несколько сложнее. 

16. Периодичность

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

17. Нумерация

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

18. Уникальность набора полей

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

19. Длина индекса

 

 

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

И последнее:

Хотя, возможно, оно должно быть первым. Проектирование должно начинаться с построения бизнес-модели и предваряться проведением анализа. При этом должны быть получены ответы на вопросы: 1) являются ли данные таблицы неотъемлемой частью элемента справочника? Например: список номенклатуры для накладной - неотъемлемая часть, а список произведенных ремонтов для оборудования - нет. 2) Согласно методики разработки 1С справочники предназначены для хранения условно-постоянной информации. Являются ли данные таблицы условно-постоянной информацией? 3) Являются ли строки таблицы объектами, на которые могут быть ссылки? Если да – то реализовывать таблицу надо вообще не регистром или табличной частью, а, например, подчиненным справочником. На вопросы необходимо ответить в рамках разрабатываемой системы, с учетом требований к разрабатываемой системе.  В зависимости от ответа на эти вопросы должен быть сделан первоначальный выбор между рассматриваемыми вариантами.

Пример такого анализа:

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

В дальнейшем, после рассмотрения всех обстоятельств, технических моментов,  вопросов доступа, UI/UX,  наше решение может быть скорректировано.

 

Что же мы получили в итоге? Как видим, при всей кажущейся простоте поставленной задачи, есть немало обстоятельств, которые необходимо учесть при проектировании качественной системы.  Очевидна необходимость тщательного анализа и требований заказчика, и структуры, и объема данных, а также методики работы с ними. Причем сделать такой анализ надо как можно раньше, чтобы потом не было мучительно больно(с) 

На этом все. Как обычно приветствуются замечания / дополнения / комментарии.

Табличная часть ТабличнаяЧасть регистр сведений РегистрСведений проектирование анализ

См. также

Табличная часть в доп. реквизитах и формирование таблиц в шаблоне docx для 1С:ДО 3.0

Адаптация типовых решений Платформа 1С v8.3 1С:Документооборот Россия Платные (руб)

Расширение конфигурации для «1С:Документооборот КОРП», редакция 3.0. позволяет: 1.использовать произвольные табличные части в качестве дополнительных реквизитов к документу; 2 использовать произвольные табличные части в шаблонах в формате docx для автоматического заполнения таблиц.

29400 руб.

29.06.2023    4452    9    4    

18

Расширение для 1С:УНФ. Автоматическое снятие резервов в Заказах покупателей

Логистика, склад и ТМЦ Адаптация типовых решений Платформа 1С v8.3 1С:Управление нашей фирмой 1.6 1С:Управление нашей фирмой 3.0 Россия Управленческий учет Платные (руб)

Чтобы не допустить путаницы с обещаниями клиентам и для четкого контроля исполнения заказов мы используем резервирование товаров. Мы доработали УНФ, чтобы она автоматически отменяла старые резервы и не мешала эффективно продавать.

7200 руб.

02.08.2023    2953    4    0    

19

Создать на основании - своя кнопка (БСП). Проблема двух подменю Создать на основании

БСП (Библиотека стандартных подсистем) Адаптация типовых решений Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

Понадобилось в подменю "Создать на основании" добавить свою команду, которая открывает обработку. В процессе доработок появилась проблема двух подменю "Создать на основании". В статье о том, как решились проблемы.

01.03.2024    1282    dimanich70    6    

13

Доработка отчета "Связанные документы" (структура подчиненности) для вывода объектов из любого расширения

Адаптация типовых решений Платформа 1С v8.3 1С:Управление торговлей 11 Россия Абонемент ($m)

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

1 стартмани

27.10.2023    1994    13    avmartynov    10    

43

Печать непроведенных документов для УТ, КА, ERP. Настройка печати по пользователям, документам и печатным формам

Пакетная печать Печатные формы Адаптация типовых решений Универсальные функции Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Абонемент ($m)

Расширение для программ 1С:Управление торговлей, 1С:Комплексная автоматизация, 1С:ERP, которое позволяет распечатывать печатные формы для непроведенных документов. Можно настроить, каким пользователям, какие конкретные формы документов разрешено печатать без проведения документа.

2 стартмани

22.08.2023    2071    21    progmaster    7    

3
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. RustIG 1351 28.10.21 09:26 Сейчас в теме
2. rpgshnik 3631 28.10.21 10:08 Сейчас в теме
В контексте данной задачи сделал бы первый вариант ТЧ в справочнике.

По второму варианту возник вопрос, тип у измерения Имя какой? И как будите решать проблему если родители "веселые" и у них два Пети.
MegasXXX; +1 Ответить
3. Alxby 1136 28.10.21 10:17 Сейчас в теме
(2) В рамках примера - абсолютно неважно какой тип у измерения Имя. А если родители "очень веселые", то у них два Пети могут быть еще и близнецами - тогда в списке детей не будет ключа (в рамках этого примера конечно же). Это будет лишним доводом за табличную часть. Интереснее будет ситуация, когда оба родителя являются сотрудниками, - здесь надо серьезно поработать аналитикам, чтобы понять как в рамках разрабатываемой системы правильно учитывать это обстоятельство.
4. Alxby 1136 28.10.21 10:35 Сейчас в теме
(3)Кстати, сейчас только мысль пришла, - ситуация, когда у детей совпадает имя и год рождения, не такая уж и нереальная - если у супругов есть дети от предыдущего брака, то они вполне могут быть одного возраста и имени.
8. rpgshnik 3631 28.10.21 11:10 Сейчас в теме
(3) говорят измерение со строковым типом моветон...
10. Alxby 1136 28.10.21 11:22 Сейчас в теме
(8)Для регистров с виртуальными таблицами - да. Для длинных строк тоже - да, легко поймать ошибку из п.19.
41. insurgut 207 10.11.21 22:39 Сейчас в теме
(3) ребенок - это физ. лицо, у которого если СНИЛС. И он у всех уникальный. Установить в качестве измерения не строку, а физ. лицо - и проблем никаких с "веселыми" родителями не будет.
43. him1974 13.11.21 18:11 Сейчас в теме
(41) Вы предлагаете всех детей "запихнуть" в справочник физлица? конфигурация ЗУП. Ну ну :)) у нас работает 30 000 + 15 000 ветеранов. Хотите добавить n-ое количество десятков тысяч в справочник? :)
44. Alxby 1136 13.11.21 21:34 Сейчас в теме
(41)Дети могут иметь иностранное гражданство, т.е. СНИЛС не будут иметь.
5. ixijixi 1775 28.10.21 10:41 Сейчас в теме
Разработчики ЗУП тоже озадачились этим вопросом, в итоге склонились к подчиненному справочнику, хотя сначала была ТЧ.
Прикрепленные файлы:
Irwin; PlatonStepan; DrAku1a; 0x00; +4 Ответить
6. Alxby 1136 28.10.21 10:48 Сейчас в теме
(5) Значит для тех задач, которые решает ЗУП, такая структура предпочтительней. Но это разумеется не предел - в данной структуре у элемента РодственникиФизическиеЛица только одна степень родства, а для каких-нибудь систем может быть важно, что Иванов Петя сын одного сотрудника и внук другого. В таком случае напрашивается отдельная таблица для родственных связей. Она тоже может быть как регистром, так и справочником(!).
itoptimum; +1 Ответить
7. rpgshnik 3631 28.10.21 11:08 Сейчас в теме
(6) На предприятие работает Дед1, у него есть сын1 и дочь1, которые так же работают на предприятие, у него есть брат1 у которого есть жена брата1 и они тоже работают на предприятие, у жены брата1 от первого брака родилась дочь2 которая работает на предприятие, у сына1 и его жены сына1 родился сын2, который тоже работает на предприятие и вступил в брак с дочерьею2, у который был сын3 от первого брака Петя, а у сына2 был так же сын4 от первого брака и его зовут Петя, родились в один год сын3 и сын4, так же у дочери2 и сына2 родился общий ребенок сын5. Вопрос как организовать степень родства на первом и втором варианте и как назовут сына5?
PlatonStepan; itoptimum; +2 Ответить
9. Alxby 1136 28.10.21 11:20 Сейчас в теме
(7)Ну, разумеется, сына5 надо назвать Петя - нельзя нарушать семейную традицию). А как организовать степень родства в системе, зависит от назначения системы и требований к ней. Возможно, что будет достаточно указанной в статье табличной части, а степень родства вообще не будет нужна. А возможен и такой вариант: справочник Сотрудники + справочник ФизическиеЛица, связанный с сотрудниками 1:1 + Регистр сведений или справочник, хранящий связи М:М между двумя элементами справочниками ФизическиеЛица, степень родства и периодом действия этой связи.
rovenko.n; +1 Ответить
11. RustIG 1351 28.10.21 11:25 Сейчас в теме
(7) пора рисовать "как максимум" графы или "как минимум" структуру подчиненности...
rpgshnik; +1 Ответить
12. Alxby 1136 28.10.21 11:30 Сейчас в теме
(11)Скорее ориентированный граф, дерева здесь будет недостаточно
RustIG; rpgshnik; +2 Ответить
28. Dragonim 139 29.10.21 07:17 Сейчас в теме
(7) У вас простая структура которая соответствует общепринятой. Существует только три вида родства сын/дочь, отец/мать, супруг/супруга, все остальные производные. Причем человек может быть только в одном виде основного родства с другим человеком, а ни как не в двух. Мы же рассматриваем общепринятую систему.

В результате достаточно ввести три предопределённых родства, после чего можно строить граф взаимосвязей.

Разумеется в реальности у вас на предприятии не будут работать все родственники, а потому в графе будет много пустых мест, которые можно заполнить если каждую степень родства разложить до базовых.

При этом построить полный граф можно только на конкретный момент времени, потому что некоторые связи не обязаны быть постоянными.
Dmitryiv; +1 Ответить
29. Alxby 1136 29.10.21 08:20 Сейчас в теме
(28)Тогда уж два - отец/мать - производное от сын/дочь. В каких-то случаях еще могут понадобиться "приемный", "опекун". Причем даже здесь возможна избыточность: то, что Петя является сыном сотрудника, однозначно следует из того, что он является сыном его жены. А в реальности вполне могут работать все родственники - какое-нибудь семейное предприятие, или традиционные ремесла в горах Кавказа, или оленеводческое хозяйство на Крайнем Севере. С тем, что связи непостоянны, согласен, причем непостоянными могут быть любая из этих связей.
rovenko.n; itoptimum; +2 Ответить
42. him1974 13.11.21 18:09 Сейчас в теме
(28) Как у Вас обстоят дела с ВУС на предприятии? Например, на нашем, сотрудникам ВУС требуются все степени родства, даже бывшая жена или муж. Для чего? А для того, что если человек был женат и развелся, далее ушел на войну и его там убили, то кому то сообщить нужно, пусть даже бывшей жене или мужу. Как то так.. Это вообще то требования нашего военкомата.
* Предприятие военное
46. Alxby 1136 13.11.21 21:44 Сейчас в теме
(42)+
А еще это может быть необходимо для обеспечения секретности, и не только на военных предприятиях
47. Alxby 1136 13.11.21 21:48 Сейчас в теме
(42)Как, кстати, у вас на предприятии с обеспечением работы с персональными данными? Если для ФОИВ согласия физического лица на хранение перс.данных не требуется, то для предприятия, наверное, оно необходимо. А если бывшая жена не даст такое согласие?
48. him1974 14.11.21 01:26 Сейчас в теме
(47) ВУСу плевать на любые информационные системы на предприятии, они военные. Если положено иметь данные по всем возможным родственникам, то они должны быть. У них приказ иметь на всех печатные персональные карточки с заполненными полями. На случай войны завод должен иметь такое то количество таких то специальностей.. и т.д.
Не хочет бывшая жена предоставлять свои перс. данные, то в инфе. удалим, ВУС - нет :)
50. Umix 131 26.11.21 00:06 Сейчас в теме
(5)

Все же не так глупы были "предки" на протяжении всей истории.
А в данном конкретной среде: нет-нет да 1С77 периодически напоминает о себе. Не так плохи были решения того времени. Точнее цели те же, инструментарии, как и способы их достижения разные.
13. RustIG 1351 28.10.21 12:21 Сейчас в теме
(0)
1. постоянно сталкиваюсь с подобными вопросами - что выбрать: ТЧ или РС? К примеру, "номенклатура поставщиков (контрагентов) - в итоге сделал через табличную часть в разрез типовому варианту регистру сведений...

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

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

То же самое можно делать с табл. частями - информацию скрыто дублировать в регистры сведений.

2. Удобство ввода - на настольном ПК , на мобильном телефоне - оно разное. Есть третий универсальный вариант - переопределять форму ввода - рисовать и программировать свою форму ввода/редактирования/удаления сведений - и уже не важно, где хранятся сведения - в ТЧ, в РС...

3. 1с - бизнес-ориентированная среда разработки... Поэтому универсально решить задачу не получится. Для вашего примера - дети нужны для чего? для расчета вычетов?
Я в свое время программировал расчет зарплаты сотрудников с учетом вычетов на детей и других вычетов - так вот просто исключил детей как сущность в управленческой программе. Не было у меня взаимосвязей между родителями и детьми (имена, пол и т.д.). Данные по детям хранились в ЗУП, в управленческой программе есть документ "Вычет" с табличной частью "Сотрудники": по каждому сотруднику вычет просто начислялся бухгалтером один раз. Из месяца в месяц документ копировался и редактировался, когда новый сотрудник нанимался, прежний - увольнялся... Хранение сведений и проверка на непротиворечивость происходит в ЗУП...
14. Alxby 1136 28.10.21 13:10 Сейчас в теме
(13)1. Дублирование информации, вообще говоря, - зло, иногда, правда, необходимое. В каждом конкретном случае должны быть веские причины, чтобы это допускать. Все дело в обеспечении согласованности данных. Раз одни и те же данные (или же данные и вычисляемые на их основе другие данные), хранятся в разных местах, то теоретически они могут быть не согласованы. Допустим ваш алгоритм работы с этими данными работает как часы, и записывает только согласованные данные. Но вы уверены, что тот, кто будет дорабатывать эту систему об этом будет знать? А если он сделает обработку, меняющую записи периодического регистра и даже не подумает о регистре с последним актуальным состоянием? Надо сделать автоматический пересчет непериодического регистра при изменении периодического? Это непросто, я слегка коснулся этого в 7 пункте. А наверное, надо еще и запретить менять непериодический без изменения периодического? А как это сделать надежно и навсегда? Хорошо, если подобные вещи заложены в платформу, но даже здесь разработчики, чтобы бороться с такими коллизиями, придумали тестирование и исправление ИБ - пересчет итогов. Поэтому и в Вашем случае необходимы средства для поиска подобных коллизий и средства для их устранения.
2. Своя форма действительно спасает во многих случаях, главное не забывать реализовать функционал, который в типовых формах есть "из коробки". Например, те же объектные блокировки.
3. Собственно в этом и был основной смысл статьи - способ решения определяется требованиями к системе, с учетом тех 19 обстоятельств, которые приведены в статье.
ixijixi; RustIG; +2 Ответить
15. RustIG 1351 28.10.21 14:05 Сейчас в теме
(14)
Дублирование информации, вообще говоря, - зло

подсистема Версии объектов - не что иное, как дублирование информации
20. Alxby 1136 28.10.21 15:02 Сейчас в теме
(15) я может ошибаюсь, но разве среди версий хранится текущая версия? или только предыдущие? В любом случае хранение версий здесь скорее всего преследует информационную цель и не влияет на основные функции системы.
16. RustIG 1351 28.10.21 14:06 Сейчас в теме
(14)
Дублирование информации, вообще говоря, - зло

В УТ уже стандарт объявлять оборотные и регистры остатков с одними и теми же измерениями... Для разных отчетов - свои системы хранения! Я еще лет 10 писал об этом публикацию на ИС.
19. Alxby 1136 28.10.21 14:58 Сейчас в теме
(16)
В УТ уже стандарт объявлять оборотные и регистры остатков с одними и теми же измерениями...

Здесь скорее всего есть одна точка изменения этих регистров - модуль проведения документа. Это существенно сглаживает проблему. До тех пор, пока не появится энтузиаст, который будет писать в регистр вне документа. А архитектура должна быть максимально устойчива к появлению таких энтузиастов.
21. RustIG 1351 28.10.21 15:17 Сейчас в теме
(19) Дублирование желательно производить в одном модуле - пример я вам предоставил.
И , кстати, я один из тех энтузиастов, которые применяет запись в регистры вне документа - у меня на этот счет была статья, положительно принятая сообществом. В общем, вы молодец, что описали тут все это.
Но это уже для некоторых пройденный этап...Я лишь попробовал расширить ваше восприятие.
23. Alxby 1136 28.10.21 15:34 Сейчас в теме
(21)Думаете я все это не применяю?))) За более 20 лет работы у меня накопился мешок таких, гм, подходов. Все, имеющие мало-мальски продолжительный опыт работы с 1С, понимают, что на практике как правило невозможно разработать архитектурно идеальную, быстро работающую в многопользовательском режиме систему без всяческих костылей ухищрений. Всегда надо искать компромисс между идеальностью, сложностью, быстродействием, скоростью разработки, удобством разработки и использования. Главное, необходимо понимать плюсы и минусы каждого проектного решения, и эти решения принимать осознанно, всячески пытаясь уменьшить негативные последствия.
26. RustIG 1351 28.10.21 16:01 Сейчас в теме
(23) ну все понятно... все уже вами детально описано в публикации... пора переходить от слов к действию :) работать, короче, надо :)))))))))))
17. RustIG 1351 28.10.21 14:08 Сейчас в теме
(14)
Раз одни и те же данные (или же данные и вычисляемые на их основе другие данные), хранятся в разных местах, то теоретически они могут быть не согласованы.


Во всех типовых такое - на ИС полно отчетов, показывающих расхождения или ошибки в учете...Это норм.
18. Alxby 1136 28.10.21 14:55 Сейчас в теме
(17) То, что это часто встречается, не делает это хорошим. Еще раз подчеркну, что если мы собрались делать нечто подобное, то мы должны а) быть уверены что плюсов будет больше, чем минусов (например существенно возрастет быстродействие, или же мы сможем реализовать необходимые разграничения доступа), б) иметь средства для поиска и исправления коллизий, регламент для использования этих средств, инструкцию, что делать, если коллизии привели к катастрофическим нежелательным последствиям. А вообще, по моему мнению, архитектура, в которой нет места подобным проблемам лучше, чем архитектура, в которой это есть, зря что ли умные люди придумали понятие "Нормальные формы"
22. RustIG 1351 28.10.21 15:21 Сейчас в теме
(18) что-то да, что-то нет....
у вас 30 клиентов, каждый ДЕНЬ кому-то что-то надо дописать в конфу - у вас нет развернутого ТЗ. У вас есть одна задача которая "перед носом", а что там понадобится через год или два - никто не знает... Делайте ТЧ если это решит задачу, делайте РС, если это лучше сейчас для отчета....

В целом, о чем вы написали, это из разряда философии "В чем смысл жизни"... Можно жить и не думать, а можно запрограммировать и на лету изменять архитектуру - пример с ЗУПом вам показали - как ТЧ переросла в ПодчиненныйСправочник....
24. Alxby 1136 28.10.21 15:48 Сейчас в теме
(22)И вновь я с частично соглашусь, а частично - нет. За что я люблю 1С - за относительную легкость изменения архитектуры. Но легкость изменения - это только техническая легкость. Если Вы будете разрабатывать тиражный массовый продукт, то Вам зададут вопрос: а после такого изменения архитектуры у всех наших 1500 клиентов ничего не сломается? И здесь уже надо будет смотреть в сторону "доказательного программирования" (термин здесь не очень подходит, но лучшего я не могу подобрать). А когда вы задумаетесь, что в принципе, теоретически, может пойти у клиента не так, то обнаружите, что чем больше "скользких" мест в архитектуре, тем больше может быть проблемных кейсов.
25. RustIG 1351 28.10.21 15:59 Сейчас в теме
(24) мы с вами говорим об одном и том же.
мы не спорим, по крайней мере я не спорю. я вас прекрасно понимаю.
вы сейчас спорите с разрабами ЗУП, у которых 1 млн пользователей, и которые трансформировали ТЧ в под. справочник.

Ну, пожурили, их, и полно, хватит...
Что с этого?
Жизнь продолжается...

Они как программировали , так и будут....

Кто хочет, почерпнет из вашей публикации дозу полезной инфы...
27. Alxby 1136 28.10.21 16:04 Сейчас в теме
(25)
мы с вами говорим об одном и том же.

я тоже пришел к такому выводу. Предлагаю на этом прекратить засорять комментарии к статье, а если необходимо - продолжим разговор в личке или очно на предстоящей конференции.
30. rovenko.n 03.11.21 11:00 Сейчас в теме
Прочел всю статью. Надеялся, что будет четкий ответ. Теперь вопросов больше, чем ответов. Спасибо тебе, автор
:-)
31. Alxby 1136 03.11.21 12:00 Сейчас в теме
(30)А кто обещал что будет легко? )) Надеюсь, что хотя бы стало понятнее как искать ответы. Удачи!
rovenko.n; +1 Ответить
32. rovenko.n 03.11.21 12:16 Сейчас в теме
(31)
стало понятнее
это да!
33. DrAku1a 1679 05.11.21 14:05 Сейчас в теме
Однозначно плюс за раскрытие темы выбора "Табличная часть или регистр сведений"!

Но неплохо бы добавить в рассмотрение подчиненный справочник, как описано в (5).
На вскидку:
Плюсы: не считывается по ссылке с основным справочником, не копируется (хотя это может быть и минусом, зависит от задачи), при этом управляется ролями и механизмы истории изменений - работают.
Минусы: сложно создавать при создании нового элемента (когда вводишь сотрудника, в этой-же карточке, не записывая, хочется наклепать ему и детей), и избыточная ссылочность (ссылка, код, пометка удаления - излишние), удалять тоже немного сложнее. Всё это решается программно.
34. Alxby 1136 05.11.21 15:07 Сейчас в теме
(33)Да, вы правы, не помешало бы такое сравнение провести. Но, как правило, если стоит выбор между объектным (ссылочным) типом и необъектным (ТЧ, регистры), то этот выбор делается быстро - здесь обычно бывает "необходимость ссылки на... " против "легкость создания/удаления". Так что я сознательно ограничил статью сравнением именно необъектных данных (кстати, на правах оффтопика, кто вспомнит еще один вид необъектных данных? Нет, это не внешние источники). А если говорить об объектных данных, то гораздо интереснее другое: какие именно объектные данные лучше использовать в том, или ином случае? Для актов (если нет проводок) что лучше - справочник или документ? а для договоров? почему? А когда лучше использовать задачи, а когда справочники? А можно документом заменить задачу? а задачу, не привязанную к бизнес-процессу? Я часто на собеседованиях подобные вопросы задаю - отличный способ проверить знания кандидата.
35. TimofeySin 164 06.11.21 14:10 Сейчас в теме
Мне нравится с регистром: Дети.СрезПоследних :) Вообще по скольку дети после 18 лет пропадают, то нужен наверное регистр :)
36. Alxby 1136 08.11.21 15:32 Сейчас в теме
(35)Далеко не во всех сферах дети пропадают после 18 лет. Даже после естественной кончины родителей, да и самих детей тоже, информация об этих родственных связях может иметь значение - например для защиты авторских прав. В нашей стране, если мне память не изменяет, это - 70 лет. Что уж говорить о правах на престол - там вообще речь может идти о столетиях))
37. SergeMalikov 571 09.11.21 15:24 Сейчас в теме
Извиняюсь может выскажусь излишне резко. Но лично мне кажется изложенные подходы к проектированию архитектуры решения несколько дилетантскими. Для хранения информации о родственных связях спроектировал бы регистр сведений с измерениями: ОбъектСвязи тип СправочникСсылка.ФизическиеЛица; СубъектСвязи тип СправочникСсылка.ФизическиеЛица; ВидСвязи тип СправочникСсылка.СтепеньРодства
38. Alxby 1136 09.11.21 16:24 Сейчас в теме
(37)А если в конфигурации нет справочника ФизическиеЛица, а есть только справочник Сотрудники? Надо завести дополнительно ФизическиеЛица? А какую информацию там хранить? Дублировать ли там данные сотрудников? или хранить там только детей? А тогда может не нужен справочник ФизическиеЛица, а нужен только справочник Дети? А как решить проблему, указанную в пункте 2? А если ссылка на справочник Дети больше нигде не понадобится, может не надо заводить регистр и справочник, а достаточно только регистра? Основная идея статьи была не в том, как правильно хранить информацию о детях, а в том, что в зависимости от требований к системе, могут быть разные решения, а при выборе решения из нескольких, необходимо учитывать факторы, приведенные в статье.
39. SergeMalikov 571 09.11.21 17:23 Сейчас в теме
(38) Если в конфигурации нет справочника ФизическиеЛица а вам необходимо хранить информацию о физических лицах то стоит его завести. Хранить в справочнике Сотрудники информацию о физических лицах (детях) это моветон. Сущности предметной области желательно использовать по назначению. При выборе архитектурного решения желательно пользоваться правилами: - не плодить новые сущности без необходимости: информацию о сотрудниках хранить в сущности "сотрудники", а информацию о физических лицах в сущности "ФизическиеЛица"; -делать архитектуру решения устойчивой к изменению требований. Сейчас вам понадобилось хранить данные о детях а завтра может понадобится хранить данные о родителях (братьях, сестрах). Будите переделывать каждый раз? При выборе решения из нескольких я бы посоветовал в первую очередь поискать аналогичное решение в типовых конфигурациях. Как говорится все уже придумали до вас.
40. Alxby 1136 09.11.21 18:25 Сейчас в теме
(39)Да, возможно, стоит добавить этот совет в статью - "при разработке архитектуры надо поискать аналогичные решения и сделать так же как сделано в них" :). А если серьезно, то нет, я не считаю, что надо бездумно копировать архитектуру чужих систем. При выборе из нескольких вариантов нужно четко понимать, чем эти варианты различаются, какие последствия принесет тот или иной выбор, что лучше для нашей системы. И это основной принцип который надо учитывать при выборе, а вовсе не "ищем что-нибудь похожее". С тем, что надо не плодить сущности - согласен, и поэтому мне непонятно, зачем нужен регистр и дополнительный справочник, когда можно обойтись табличной частью (разумеется, если такой вариант полностью покрывает требования заказчика). С тем, что надо делать систему устойчивой к изменениям - тоже согласен, но с оговоркой, что надо оценить вероятность этих изменений и сложность вариантов. Но эта тема выходит далеко за рамки статьи. Вот представьте, что к вам пришел новый сотрудник, которого вы должны обучить, как разрабатывать архитектуру. Вы можете изложить ход своих рассуждений, которые приводят к тому, что для связи ОбъектаСвязи и СубъектаСвязи вы выбрали регистр, а не табличную часть?
unknown181538; RustIG; +2 Ответить
49. RustIG 1351 14.11.21 10:03 Сейчас в теме
(39)
Как говорится все уже придумали до вас.

На самом деле, еще никто не придумал до нас "всё"...
Исторически складывается так - что все экспериментируют, учатся на своих ошибках....
Обсуждают иногда на форумах... Но окончательного идеального решения нет - до сих многие сферы учета находятся в зачаточном состоянии...

Вот пример из жизни - лет 10 назад в типовых было так:
инвентарный номер основного средства в справочнике - это код справочника ОсновныеСредства;
табельный номер сотрудника - это код справочника Сотрудники,
затем через два года разработчики типовых изменили свое мнение - сделали эти сущности отдельными реквизитами....
Я об этом писал в публикации "Перенумерация кодов справочников и номеров документов"...

Разработка (в том числе изменение архитектуры решения) - весьма гибкая и изменчивая сущность....
Короче, никто еще не придумал до нас "всё"...
unknown181538; +1 Ответить
45. Alxby 1136 13.11.21 21:41 Сейчас в теме
Как интересно расходятся ветки комментариев... Я наверное перемудрил с названием, может надо было просто назвать статью "Сравнение ТЧ и РС":) ? Но, в любом случае, спасибо всем участником обсуждения - нашел для себя несколько тем для обдумывания.
Оставьте свое сообщение