Много узкоспециализированных объектов или небольшое количество универсальных? Истина, как обычно, посередине. Справочники и документы в 1С - это пример удачного попадания в эту середину. Разумеется, речь не о том, что видит пользователь, а о том, чем оперирует разработчик. Идея " а давайте у нас будут не таблицы базы данных, а справочники и документы", при всей своей внешней неброскости, не столь проста. О чем и поговорим далее

Вступление

Мы стартуем с того, что часть таблиц базы данных в обязательном порядке снабжаем полем типа дата и называем их документами. Другая часть таблиц может иметь в своем составе поля типа дата, а может и не иметь. Их мы называем справочниками. И те и другие, как и почти все порядочные таблицы баз данных, имеют поле уникального идентификатора, он же первичный ключ. Разработчикам не надо заботится о создании этих полей и ключей. Платформа 1С:Предприятие сделает это за них. Разработчики могут пользоваться результатами работы платформы и связывать документы и справочники друг с другом всевозможными способами. Значения уникальных идентификаторов формируются автоматически.

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

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

Справочники

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

• Код

• Наименование

• Владелец

• Родитель

• ЭтоГруппа

• ПометкаУдаления

• Предопределенный

• ИмяПредопределенныхДанных

Некоторые из них заслуживают более подробного рассказа.

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

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

Но тут "особо умных" ждет подвох

Мы-то удалили код из справочника, а платформа не совсем.

Этому багу уже лет двадцать. Поначалу я на него сердился, а теперь кажется, что мне будет его не хватать, если его когда-нибудь исправят.

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

Одна "галочка" и пользователь получает у себя перед глазами красивое "дерево", а разработчик такие методы как ПринадлежитЭлементу() и ВыбратьИерархически().

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

Документы

Как я уже говорил, у документа кроме ссылки есть поле дата. Это позволяет рассматривать документы как инструмент отображения событий. Есть еще три предопределенных поля:

• Номер

• Проведен

• ПометкаУдаления

Можно добавлять табличные части. Но самое интересное в документах - это то, что у них как правило есть движения. Движения это записи в регистрах накопления (регистрах бухгалтерии, регистрах расчета, реже в регистрах сведений) связанные с документом. В самых простых случаях нет необходимости писать код для формирования движений (а в сложных есть такая возможность!). Можно воспользоваться конструктором движений.

Три (если у вас "+", "приход") или четыре клика (если у вас "-", "расход") и платформа создаст вам код

Процедура ОбработкаПроведения(Отказ, РежимПроведения)
	//{{__КОНСТРУКТОР_ДВИЖЕНИЙ_РЕГИСТРОВ
	// Данный фрагмент построен конструктором.
	// При повторном использовании конструктора, внесенные вручную изменения будут утеряны!!!

	// регистр ОстаткиТоваров Приход
	Движения.ОстаткиТоваров.Записывать = Истина;
	Для Каждого ТекСтрокаТовары Из Товары Цикл
		Движение = Движения.ОстаткиТоваров.Добавить();
		Движение.ВидДвижения = ВидДвиженияНакопления.Приход;
		Движение.Период = Дата;
		Движение.Товар = ТекСтрокаТовары.Товар;
		Движение.Количество = ТекСтрокаТовары.Количество;
	КонецЦикла;

	//}}__КОНСТРУКТОР_ДВИЖЕНИЙ_РЕГИСТРОВ
КонецПроцедуры

Быстрая разработка

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

Такое простое разделение как бы берет за руку неопытного разработчика и ведет его к результату. Нам нужен учет на складе? Хорошо, какие у нас будут документы? Очевидно, что как минимум, для начала, приход на склад и расход со склада. А что в документах? В документах ссылки на справочники склады, товары и т.д. Ну и количество, разумеется. И все это делается за считанные минуты даже теми, кто никогда раньше не видел 1С. Еще несколько минут и мы создали регистр остатков товаров на складе, с помощью конструктора движений сгенерировали код для документов прихода и расхода. В принципе, наша учетная система уже готова к использованию. Можно еще создать отчет. Также с помощью конструктора. И так же быстро, как все остальное. Но это тема отдельного интересного разговора.

Заключение

В бурно развивающихся и постоянно меняющихся ИТ иногда встречаются "долгоиграющие" темы. Хороший пример тому язык запросов SQL. Вывод разработчика на уровень абстракции справочники/документы появился в 1С четверть века назад. И это прекрасно работает до сих пор. Что и служит доказательством удачной находки.

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

• Подробнее про бесплатный вебинар