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

Публикация № 1489073 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,  наше решение может быть скорректировано.

 

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

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

Специальные предложения

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

См. также

Аналог PIVOT в запросе 1С (как выполнить транспонирование таблицы в запросе 1С) Промо

Практика программирования v8 Бесплатно (free)

В статье показывается простой метод реализации аналога оператора PIVOT в запросе 1С без использования соединений.

12.12.2020    4694    Eugen-S    23    

СКД: 5 советов, как сделать лучше

Практика программирования v8 v8::СКД 8.3.14 Бесплатно (free)

Несколько примеров решения задач с использованием разных подходов

27.10.2021    4735    Neti    19    

Полезные примеры СКД, ч.2

Практика программирования v8 v8::СКД Бесплатно (free)

Еще несколько примеров решения задач в СКД.

06.04.2021    11046    Neti    8    

Неочевидные нюансы записи управляемой формы

Практика программирования v8 v8::УФ Платформа 1C v8.2 1cv8.cf Бесплатно (free)

Разберем несколько нюансов записи управляемой формы.

02.04.2021    13317    SeiOkami    54    

Использование классов .Net в 1С для новичков Промо

Разработка внешних компонент Универсальные функции Практика программирования v7.7 v8 Бесплатно (free)

Руководство для новичков. Написав статью http://infostart.ru/public/238584/, я понял, что многие не понимают того, что написано. Поэтому в этой статье постараюсь более подробно остановиться на азах и без кода на вражеском языке (C#)

27.01.2016    86027    Serginio    116    

Обзор полезных методов БСП 3.1.4

БСП (Библиотека стандартных подсистем) Практика программирования v8 1cv8.cf Бесплатно (free)

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

25.03.2021    42703    rayastar    51    

Звуковое управление в 1С 8.3

Практика программирования v8 1cv8.cf Бесплатно (free)

В данной статье описано создание библиотеки для звукового управления (выполнение команд голосом) для платформы 1С 8.3. Задача была поставлена так, чтобы модуль функционировал непосредственно на клиенте 1С, осуществляя управление формами, и взаимодействовал с интерфейсом.

16.03.2021    7327    velemir    33    

Доработка проведения в ERP 2.5. (Регистры накопления, Регистры сведений)

Практика программирования v8 ERP2 БУ Бесплатно (free)

Покажу точки входа для доработки "типового" проведения документов в ERP для регистров оперативного учета. Рассмотрим три основные ситуации: нужно изменить имеющееся проведение документа; нужно сделать записи в существующие регистры; нужно с нуля описать алгоритм проведения в добавленный регистр. Пример реализован на 1С:ERP Управление предприятием 2 (2.5.4.120)

10.01.2021    11105    BuriyLesha    10    

Использование программных перечислений, ч.1: строковые константы Промо

Практика программирования v8 1cv8.cf Бесплатно (free)

Часто ли у вас возникает необходимость в коде выполнять сравнение на строку?

10.12.2016    41218    unichkin    74    

Serverless (Faas) в 1С. Создание и вызов Yandex Cloud Functions

Универсальные функции Практика программирования v8 Бесплатно (free)

"Я не могу просто взять и скопировать код с гитхаба", "у нас 1С микросервисами окружена", "возможностей мало" - частые фразы 1С разработчиков. которым не хватает возможностей платформы в современном мире. Faas, конечно, история не новая, но нас сдерживало 152ФЗ и задержки по пингам. Для того, чтобы действительно использовать в 1С код, к примеру, на Python, надо было приложить усилия. Теперь всё намного проще - берём и используем.

28.12.2020    9067    comol    31    

Базовые вещи БСП, которые облегчат жизнь программисту 1С

БСП (Библиотека стандартных подсистем) Практика программирования v8 1cv8.cf Россия Бесплатно (free)

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

30.08.2020    20621    quazare    34    

Вспомогательные инструкции в коде 1С Промо

Практика программирования v8 1cv8.cf Бесплатно (free)

Помогаем редактору кода 1С помогать нам писать и анализировать код.

15.10.2018    36289    tormozit    106    

Возможности работы со строками при помощи БСП, которые должен знать каждый программист

БСП (Библиотека стандартных подсистем) Практика программирования v8 Бесплатно (free)

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

05.07.2020    14130    quazare    37    

Серверные вызовы, которые нельзя вызывать

Практика программирования v8 v8::УФ 1cv8.cf Бесплатно (free)

Не баян, а классика. Рассмотрим особенность платформы настолько же древнюю, как сами УФ.

12.05.2020    9484    SeiOkami    34    

Форма выбора (подбор) в управляемых формах

Практика программирования v8 v8::УФ 1cv8.cf Россия Бесплатно (free)

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

08.05.2020    81487    user5300    24    

Оформление и рефакторинг сложных логических выражений Промо

Практика программирования v8 Россия Бесплатно (free)

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

20.09.2012    82973    tormozit    131    

Конвертация расширения cfe в конфигурацию сf руками

Практика программирования v8 1cv8.cf Бесплатно (free)

Как быстро преобразовать расширение в конфигурацию (для дальнейшего переноса в основную конфигурацию, например).

18.03.2020    11020    wtlz    35    

Программная работа с настройками СКД

Практика программирования v8 v8::СКД 1cv8.cf Бесплатно (free)

Нюансы программной работы с настройками системы компоновки данных в отчетах и динамических списках. Обзор всех видов настроек компоновки. Что в каких случаях правильно применять. В качестве примера рассмотрена работа с отборами и группировками.

27.01.2020    67086    ids79    27    

[СКД] Программное создание схемы компоновки данных

Практика программирования v8 v8::СКД 1cv8.cf Бесплатно (free)

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

15.01.2020    44363    John_d    22    

Запись значения в поле ввода/формы со срабатыванием события ПриИзменении Промо

Практика программирования v8 1cv8.cf Россия Бесплатно (free)

Иногда возникает необходимость после записи значения в какое либо поле ввода/формы вызвать для него обработчик события ПриИзменении, а о вызове самого события приходится только мечтать. В этой статье приводится программный способ вызова этого события.

11.07.2007    54640    tormozit    51    

Последовательности событий при проведении документа 1С. Шпаргалка + про формы + про расширения

Практика программирования v8 Россия Бесплатно (free)

Собрал информацию о событиях/подписках/расширениях в одном месте.

30.12.2019    36103    kuzyara    38    

30 задач. Странных и не очень

Практика программирования v8 Бесплатно (free)

30 задач на знание языка программирования 1С и некоторого поведения платформы. Маленьких. Странных и не очень.

02.12.2019    24603    YPermitin    63    

Обновление релиза измененной типовой конфигурации

Практика программирования v8 1cv8.cf Бесплатно (free)

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

29.11.2019    15502    John_d    76    

Как сделать из &НаКлиентеНаСервереБезКонтекста почти &НаКлиентеНаСервере Промо

Практика программирования v8 1cv8.cf Россия Бесплатно (free)

Как сделать метод формы, доступный на клиенте и на сервере одновременно, и сохранить при этом удобство разработки

10.09.2017    51436    tormozit    74    

Как передать IP адрес, который вызвал HTTP запрос в 1C (для веб-сервера Apache)

Практика программирования v8 Бесплатно (free)

Столкнулся с задачей получения IP адреса, который вызывает http сервис 1С. Итак, решение:

22.11.2019    12497    Sibars    19    

Таблица значений. Нюансы

Практика программирования v8 Бесплатно (free)

Обзор некоторых аспектов использования общеизвестного инструмента 1С.

01.10.2019    53810    Yashazz    56    

[Шпаргалка] Программное создание элементов формы

Работа с интерфейсом Практика программирования v8 1cv8.cf Бесплатно (free)

Программное создание практически всех популярных элементов формы.

06.09.2019    104897    rpgshnik    77    

Выгрузка документа по условию Промо

Инструментарий разработчика Практика программирования v8 Бесплатно (free)

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

25.04.2019    18086    m-rv    3    

Агрегатные функции СКД, о которых мало кто знает

Практика программирования v8 v8::СКД 1cv8.cf Бесплатно (free)

Пользуетесь ли Вы всеми возможными агрегатными функциями, которые предоставляет система компоновки данных? Если Вы используете только: СУММА, КОЛИЧЕСТВО, МИНИМУМ, МАКСИМУМ, СРЕДНЕЕ, то эта статья для Вас.

05.09.2019    78916    ids79    56    

Регистры бухгалтерии. Общая информация

Математика и алгоритмы Практика программирования v8 v8::БУ БУ Бесплатно (free)

Общая информация о внутреннем устройстве регистров бухгалтерии.

05.09.2019    47364    YPermitin    25    

Три костыля. Сказ про фокусы в коде

Практика программирования v8 Бесплатно (free)

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

03.09.2019    30337    YPermitin    81    

Как прикрутить ГУИД к регистру сведений Промо

Перенос данных из 1C8 в 1C8 Инструментарий разработчика Практика программирования v8 Бесплатно (free)

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

16.04.2019    23436    m-rv    18    

Отслеживание выполнения фонового задания

Универсальные функции Инструментарий разработчика Практика программирования v8 1cv8.cf Бесплатно (free)

Запуск фонового задания из модуля внешней обработки. Отслеживание выполнения задания в виде прогресса, расположенного на форме.

17.08.2019    45613    ids79    22    

Функции СКД: ВычислитьВыражение, ВычислитьВыражениеСГруппировкойМассив

Практика программирования v8 v8::СКД 1cv8.cf Бесплатно (free)

Подробное описание и использование внутренних функций системы компоновки данных: Вычислить, ВычислитьВыражение, ВычислитьВыражениеСГруппировкойМассив, ВычислитьВыражениеСГруппировкойТаблицаЗначений.

08.08.2019    155266    ids79    75    

Фоновое выполнение кода в 1С - это просто

Практика программирования v8 1cv8.cf Бесплатно (free)

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

02.08.2019    61730    avalakh    27    

Как сделать запрос на изменение данных Промо

Практика программирования v8 v8::Запросы 1cv8.cf Бесплатно (free)

В статье приведены особенности внутренней архитектуры и примеры работы с расширением языка запросов 1С.

01.06.2018    37231    m-rv    23    

Разбираемся с параметрами редактирования СКД

Практика программирования v8 v8::СКД 1cv8.cf Бесплатно (free)

Связь по типу, Параметры выбора, Связи параметров выбора

31.07.2019    42620    json    17    

СКД - наборы данных и связи между ними, создание собственной иерархии, вложенные отчеты

Практика программирования v8 v8::СКД 1cv8.cf Бесплатно (free)

Набор данных объект. Использование в схеме компоновки нескольких наборов данных. Различные варианты связи наборов: объединение, соединение. Использование иерархии в отчетах на СКД. Создание собственной иерархии, иерархия детальных записей. Использование вложенных схем в отчетах на СКД.

26.07.2019    107378    ids79    17    

СКД - использование расширений языка запросов, секция ХАРАКТЕРИСТИКИ

Инструментарий разработчика Практика программирования v8 v8::СКД Бесплатно (free)

Автоматическое и не автоматическое заполнение полей компоновки данных. Использование расширений языка запросов для СКД «{…}», секция ВЫБРАТЬ, секция ГДЕ, параметры виртуальных таблиц. Автоматизированное использование дополнительных данных в запросе: секция ХАРАКТЕРИСТИКИ.

17.07.2019    48981    ids79    27    

Метод формирования движений в типовых регистрах нетиповыми регистраторами Промо

Практика программирования v8 1cv8.cf Бесплатно (free)

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

05.12.2017    30826    itriot11    34    

Регистры сведений. За кулисами

Инструментарий разработчика Практика программирования v8 1cv8.cf Бесплатно (free)

Небольшие заметки по внутреннему устройству регистров сведений.

09.07.2019    34266    YPermitin    15    

"Меньше копипаста!", или как Вася универсальную процедуру писал

Практика программирования v8 v8::СКД 1cv8.cf Бесплатно (free)

Программист Вася разбирает подход создания универсальных методов на примере программного вывода СКД.

04.07.2019    22648    SeiOkami    53    

Работа с настройками системы компоновки данных

Практика программирования v8 v8::СКД 1cv8.cf Бесплатно (free)

Варианты отчетов, работа с настройками вариантов: структура группировок, поля отчета, отборы, сортировка, условное оформление, другие настройки, настройки отображения диаграмм.

02.07.2019    85728    ids79    18    

Регистры накопления. Виртуальные таблицы. Часть №2: "Остатки" и "Остатки и обороты"

Практика программирования v8 1cv8.cf Бесплатно (free)

Описание работы платформы 1С:Предприятие 8.2 с виртуальными таблицами регистров накопления "Остатки" и "Остатки и обороты". Анализ SQL-запрос при работе с виртуальными таблицами

22.05.2019    45209    YPermitin    8    

Регистры накопления. Виртуальные таблицы. Часть №1: Обороты

Математика и алгоритмы Инструментарий разработчика Практика программирования v8 1cv8.cf Бесплатно (free)

Описание работы платформы 1С:Предприятие 8.2 с виртуальной таблицей "Обороты" регистров накопления.

20.05.2019    46887    YPermitin    8    

Регистры накопления. Структура хранения в базе данных

Инструментарий разработчика Практика программирования v8 1cv8.cf Бесплатно (free)

Структура хранения регистров накопления в базе данных для платформы 1С:Предприятие 8.x. Первая часть в серии публикаций.

16.05.2019    64786    YPermitin    31    

О расширениях замолвите слово...

Инструментарий разработчика Практика программирования v8 Бесплатно (free)

О чём стоит задуматься при принятии решения о создании расширения конфигурации…

07.04.2019    42933    ellavs    131