Как составить свой справочник

• в веб-приложении нажмите кнопку «Создать»
  главного меню и выберите тип объекта на боковой панели «Новый объект»;

Веб-приложение
Настольное приложение

Создание справочников возможно только через веб-интерфейс портала ЕСНСИ. Пользователю ЕСНСИ доступно два способа создания справочников через веб-интерфейс: вручную либо через автоматическую загрузку структуры справочника.

Создание структуры справочника вручную

В ЕСНСИ доступно создание следующих типов справочников:

• Простой тип;
• Агрегатор простых справочников;
• Иерархический справочник;
• Справочный файл.

Создание справочника типа «Простой справочник»

Простой справочник – тип справочника, представляющий собой массив данных с заданной Пользователем структурой.

Для создания справочника в интерфейсах системы необходимо выполнить следующие действия:

1.      Перейти на экранную форму Список справочников (Рисунок 1).

Рисунок 1 – Список справочников.

2.      Нажать кнопку Добавить справочник.

3.      Система отобразит экран Создание справочника, шаг первый – Реквизиты, тип Простой справочник (Рисунок 2).

Рисунок 2 – Создание простого справочника.

4.      Заполнить поле Наименование справочника. Название справочника должно быть уникальным в рамках группы.

5.      Заполнить поле Описание справочника (опционально).

6.      Выпадающий список с указанием типа справочника будет предустановлен на справочник типа Простой справочник.

7.      Выбрать в поле Глубина ревизии значение из выпадающего списка:

• Хранить последние пятьдесят – означает, что у справочника в истории ревизий (изменений справочника) будет доступно только последние пятьдесят ревизий;
• Хранить последние десять – означает, что у справочника в истории ревизий будет доступно только последние десять ревизий;
• Хранить последние две – означает, что у справочника в истории ревизий будет доступно только две последние ревизий.

8.      Заполнить поле Код. Введенное значение должно быть уникальным в рамках системы.

9.      Выбрать в поле Группа справочника из выпадающего списка.

10.      Выбрать в поле Доступ к справочнику уровень доступа из выпадающего списка:

• Публичный – возможен просмотр справочника в неавторизованной зоне;
• Не публичный – просмотр возможен только для авторизованных пользователей;
• Ограниченный – просмотр возможен только пользователям, входящим в указанную группу.

11.      Установить метку в поле Автоматическое распространение изменений справочника (опционально, устанавливается только для справочников, требующих распространение обновлений).
Данная отметка означает, что все изменения справочников будут попадать в рассылку изменений справочников через СМЭВ посредством ВС:

• Рассылка обновлений справочников ЕСНСИ;
• Рассылка инкрементного обновления справочника ЕСНСИ по идентификаторам.

12.      Нажать кнопку Продолжить (данная кнопка станет активной после заполнения всех обязательных полей).

Система отобразит экран шаг второй – Атрибуты, тип Простой справочник (Рисунок 3), для создания структуры справочника.

Рисунок 3 – Создание атрибутов справочника.

13.      Заполнить поле Наименование атрибута. Название должно быть уникальным в рамках справочника, справочник должен содержать как минимум один атрибут.

14.      Указать необходимый тип атрибута:

• Строка;
• Целое число;
• Дата;
• Дробное число;
• Ссылка;
• Логический;
• Текст.

15.      Заполнить опциональное поле Выражение (регулярное выражение для атрибутов с типом Строка и Текст, по которому будет валидироваться заполняемое значение данного атрибута)

16.      Для создания дополнительного атрибута необходимо нажать на кнопку Добавить атрибут, таким же образом создать и заполнить необходимое количество атрибутов справочника.

17.      Установить метку База составного ключа (не менее одного и не более трех для создаваемого справочника) для атрибута.
Составной ключ – это идентификатор, обеспечивающий уникальность записи справочника. Отметка необходима для автоматического создания атрибута – автоключа, указывающего на уникальность записи, редактирование данного атрибута вручную запрещено.
Данную отметку можно установить только для атрибутов следующих типов:

• Строка;
• Целое число;
• Дата;
• Дробное число.

В случае, если данная метка присутствует – метка Обязательность заполнения ставится автоматически, без права отмены. При установки данной метки и заполнении данных атрибута появляется поле Структура составного ключа (Рисунок 4), с возможностью выбора из выпадающего списка очередности заполнения частей составного ключа.

Рисунок 4 – Создание ключевого атрибута.

18.      Для сохранения структуры и атрибутов справочника необходимо воспользоваться кнопкой Сохранить, после чего произойдет сохранение всех внесенных данных и возврат к списку справочников. При отсутствии атрибутов кнопка Сохранить недоступна.

19.      Для отмены внесенных изменений необходимо нажать на кнопку Отмена, после чего отобразится всплывающее сообщение с подтверждением (Рисунок 5). При нажатии на кнопку Выйти произойдет отмена и удаление всех изменений, при нажатии на Отмена – возврат к созданию справочника.

Рисунок 5 – Выход со страницы создания справочника.

ВАЖНО! Название справочника должно быть уникальным в рамках группы (справочники, не принадлежащие одной группе, могут иметь совпадающие названия). При попытке сохранить справочник с повторяющимся наименованием система отобразит уведомление (Рисунок 6).

Рисунок 6 – Ошибка уникальности имени справочника.

ВАЖНО! Код справочника должен быть уникальным в рамках системы. При попытке сохранить справочник с повторяющимся кодом система отобразит уведомление (Рисунок 6).

Создание справочника типа «Справочник-агрегатор простых справочников»

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

Для создания справочника данного типа необходимо оформить заявку через СЦ МЦ —  https://sc.digital.gov.ru, приложив две заполненные формы (1 и на создание справочника-агрегатора).

Создание иерархического справочника

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

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

1.      Перейти на экранную форму Список справочников (Рисунок 1).

2.      Нажать кнопку Добавить.

3.      Система отобразит экран Создание справочника типа Простой справочник (Рисунок 2).

4.      Заполнить поле Наименование справочника, название справочника должно быть уникальным в рамках группы.

5.      Заполнить поле Описание (опционально).

6.      Установить в выпадающем списке Тип справочника Иерархический справочник (Рисунок 7).

Рисунок 7 – Создание иерархического справочника.

7.      Заполнить поле Код, введенное значение должно быть уникальным в рамках системы.

8.      Выбрать в поле Группа группу справочника из выпадающего списка.

9.      Выбрать в поле Доступ к справочнику уровень доступа из выпадающего списка:

• Публичный – возможен просмотр справочника в неавторизованной зоне;
• Не публичный – просмотр возможен только для авторизованных пользователей;
• Ограниченный – просмотр возможен только пользователям, входящим в указанную группу.

10.      Установить метку в поле Автоматическое распространение изменений справочника (опционально, устанавливается только для справочников, требующих распространение обновлений).

Данная отметка означает, что все изменения справочников будут попадать в рассылку изменений справочников через СМЭВ посредством ВС:

• Рассылка обновлений справочников ЕСНСИ;
• Рассылка инкрементного обновления справочника ЕСНСИ по идентификаторам.

11.      Нажать кнопку Продолжить (данная кнопка станет активной после заполнения всех обязательных полей). Сохранено метаописание справочного файла.

12.      Система отобразит экран шаг второй – Атрибуты (Рисунок 8), для создания структуры справочника.

Рисунок 8 – Создание атрибутов иерархического справочника.

13.      Заполнить поле Наименование атрибута, название атрибута должно быть уникальным в рамках справочника, справочник должен содержать как минимум один атрибут.

14.      Указать необходимый тип атрибута:

• Строка;
• Целое число;
• Дата;
• Дробное число;
• Ссылка;
• Логический;
• Текст.

15.      Заполнить опциональное поле Выражение (регулярное выражение для атрибутов с типом Строка и Текст, по которому будет валидироваться заполняемое значение данного атрибута)

16.      Для создания дополнительного атрибута необходимо нажать на кнопку Добавить атрибут, таким же образом создать и заполнить необходимое количество атрибутов справочника.

17.      Установить метку Ключевой атрибут (только один для данного типа справочника). Для данных атрибутов доступны следующие типы:

• Строка;
• Целое число;
• Дата;
• Дробное число.

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

18.      Для сохранения структуры и атрибутов справочника необходимо воспользоваться кнопкой Сохранить, после чего произойдет сохранение всех внесенных данных и возврат к списку справочников. При отсутствии атрибутов кнопка Сохранить не доступна.

19.      Для отмены внесенных изменений необходимо нажать на кнопку Отмена, после чего отобразится всплывающее сообщение с подтверждением (Рисунок 5). При нажатии на кнопку Выйти произойдет отмена и удаление всех изменений, при нажатии на Отмена – возврат к созданию справочника.

ВАЖНО! На этапе сохранения для данного типа справочника автоматически заведется атрибут с именем Родительский атрибут с типом ссылка. Данный атрибут необходим для создания структуры иерархии и является вспомогательным атрибутом.

Создание справочника из файла

Данный способ создания справочника позволяет пользователю ЕСНСИ выполнить автоматическую загрузку структуры справочника.

Для создания справочника в интерфейсах системы необходимо выполнить следующие действия:

1.      Перейти на экранную форму Список справочников (Рисунок 8).

2.      Нажать кнопку Добавить из файла.

3.      Система отобразит экран Создание справочника из файла (Рисунок 9).

Рисунок 9 – Создание справочника из файла.

4.      Загрузить файл в формате xml или zip:

• XML – данный вид файла должен соответствовать принятой структуре XML файла в системе, структуру можно скачать в виде XSD схемы на форме создания справочника (Рисунок 9). Если структура файла не соответствует существующей структуре справочника, справочник не будет создан;
• ZIP – данный вид файла должен содержать в себе один файл обновления в формате xml, название которого должно быть написано латиницей. Этот вид файла пользователю необходимо использовать, если размер загружаемого файла в формате xml/csv превышает 350Мб.

5.      Нажать кнопку Загрузить вручную.

6.      Выбрать файл для импорта.

7.      Название выбранного файла отобразится в поле Файл.

8.      Проверить правильность выбранной кодировки загруженного файла справочника (по умолчанию для XML файла выбирается кодировка UTF-8).

9.      Установить метку в поле Автоматическая загрузка данных после создания структуры (опционально, устанавливается только для справочников, требующих распространение обновлений).

10.      Выбрать в поле Глубина ревизии (доступно для простого типа справочника) значение из выпадающего списка:

• Хранить последние пятьдесят – означает, что у справочника в истории ревизий (изменений справочника) будет доступно только последние пятьдесят ревизий;
• Хранить последние десять – означает, что у справочника в истории ревизий будет доступно только последние десять ревизий;
• Хранить последние две – означает, что у справочника в истории ревизий будет доступно только две последние ревизий.

11.      Выбрать в поле Группа группу справочника из выпадающего списка.

12.      Выбрать в поле Доступ к справочнику уровень доступа из выпадающего списка:

• Публичный – возможен просмотр справочника в неавторизованной зоне;
• Не публичный – просмотр возможен только для авторизованных пользователей;
• Ограниченный – просмотр возможен только пользователям, входящим в указанную группу.

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

14.   Для отмены внесенных изменений необходимо нажать на кнопку Отмена, после чего отобразится всплывающее сообщение с подтверждением (Рисунок 5). При нажатии на кнопку Выйти произойдет отмена и удаление всех изменений, при нажатии на Отмена – возврат к созданию справочника.

Создание справочного файла

Справочный файл – тип справочника без заданной в ЕСНСИ структуры, распространяемый в формате, заданном Пользователем.

Для создания справочного файла необходимо обратиться в СЦ МЦ —  https://sc.digital.gov.ru

Для создания своего собственного справочника придется немного «покодить»😉 

Создать свой справочник вы можете через Администрирование — Исходные коды

Интерфейс раздела «Исходные коды»  

1. Создание пакета

---

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

Справочник не может существовать без пакета, поэтому, если список справочников еще пуст, создайте пакет:

Файл: ExampleDictionary.bl

И выбираем пакет, в который поместим справочник.

Файл создали, теперь его нужно заполнить. 

Разберем поэтапное наполнение справочника

Импорты. 

Всегда указываем импорты, приведенные ниже: 

import org.zenframework.z8.base.table.Table;
import pro.doczilla.dictionary.importFile.CsvDictionaryImportAction;

Дополнительно вписываем импорты типов данных, которыми будем пользоваться в справочнике. В справочнике планируется колонка «Имя»? Значит нужно текстовое поле, импортируем — 

import org.zenframework.z8.base.table.value. StringField;

Полный список импортов в таблице ниже

Класс	Описание	Строка импорта
StringField	Строка	import org.zenframework.z8.base.table.value. StringField;
TextField	Текст	import org.zenframework.z8.base.table.value. TextField;
DateField	Дата	import org.zenframework.z8.base.table.value. DateField;
DatetimeField	Дата и время	import org.zenframework.z8.base.table.value. DatetimeField;
BoolField	Логическое	import org.zenframework.z8.base.table.value. BoolField;
IntField	Целое число	import org.zenframework.z8.base.table.value. IntField;
DecimalField	Число	import org.zenframework.z8.base.table.value.DecimalField;

Шапка справочника

[generatable]
[dictionary]
[request true]
[name "ExampleDictionary"]
[displayName "Название справочника"]
public class ExampleDictionary extends Table {
}

При задании класса указываем в скобках [] следующие атрибуты:

• name – название справочника, такое же, как вы указали при создании
• displayName – название справочника для пользователей
• public class ExampleDictionary extends Table — также нужно указать наименование справочника

Столбцы справочника

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

   [name "ADDRESS"]
   [displayName "Адрес регистрации"]
   public StringField address;
   address.length = 200;
   address.colSpan = 2;

• name – системное наименование колонки таблицы справочника;
• displayName – отображаемое наименование столбца справочника для пользователя;
• StringField – тип поля справочника (для каждого типа поля должна быть добавлена соответствующая строка импорта в класс). Здесь же указывается системное наименование столбца = name;
• address.length — максимальная длина поля. не забываем подменить «address» на свое наименование;
• address.colSpan — ширина столбца (на примере 2/12 экрана).

Таким образом прописываются все столбцы справочника.

Порядок отображения колонок справочника

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

columns = { firstField, secondField }; 
controls = { firstField, secondField };

• columns — в {} перечисляем колонки в порядку, в котором поля войдут в справочник.

Таким образом, вы можете добавлять и убирать поля, не убирая их из кода. А также переопределять порядок полей.

Итоговый пример справочника

import org.zenframework.z8.base.table.Table;
import org.zenframework.z8.base.table.value.StringField;
import pro.doczilla.dictionary.importFile.CsvDictionaryImportAction;

[generatable]
[dictionary]
[request true]
[name "test123"]
[displayName "Справочник"]
public class test123 extends Table {

        [name "NamePerson"]
	[displayName "ФИО Уполномоченного"]
	public StringField nameperson;
	nameperson.length = 200;
	nameperson.colSpan = 1;

	[name "PositionPerson"]
	[displayName "Должность Уполномоченного"]
	public StringField positionperson;
	positionperson.length = 200;
	positionperson.colSpan = 1;

        [name "FoundationDocument"]
	[displayName "Документ основания"]
	public StringField foundationdocument;
	foundationdocument.length = 200;
	foundationdocument.colSpan = 1;

	[name "Banned"]
	[displayName "Заблокирован"]
	public StringField banned;
	banned.length = 200;
	banned.colSpan = 1;


	columns = {nameperson, positionperson, foundationdocument, banned};

	controls = {nameperson, positionperson, foundationdocument, banned};

	CsvDictionaryImportAction importAction;
	actions = {importAction};
     
}

Очистка справочника

Для очистки справочника, необходимо дополнительно импортировать класс:

import pro.doczilla.dictionary.action.ClearAction;

И строки в конце кода:

CsvDictionaryImportAction importAction;
actions = {importAction};

Переделать следующим образом:

CsvDictionaryImportAction importAction;
ClearAction clearAction;
actions = {clearAction,  importAction};  

3. Добавление справочника

---

Когда код справочника написан, необходимо запустить его в работу. 

Запуск компиляции

Генерация схемы данных (Администрирование — Генерация схемы данных)

Включение справочника в разделе Настрйоки — Справочники

Поздравляем! Теперь справочник виден пользователям и готов к работе!

Was this article helpful?

Что такое справочники данных?

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

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

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

Почему необходимы определения для данных

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

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

Для примера: вы получаете данные с мобильного приложения, и на 3 дня инструментарий был недоступен в связи с поломкой. Теперь разрыв в 3 дня будет в ваших данных навсегда. Без необходимой документации, информирующей всех об этой аномалии, ваши данные будут выглядеть странно. И так как в документации будет указан источник данных с определением полей данных, каждому кто её читает важно понимать основные принципы сбора данных: иногда инструменты неправильно откалиброваны или неисправны. Более того вычисления над данными меняются по мере изменения бизнес-процессов.

Когда надо делать справочники данных?

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

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

Роли и ответственность?

Владелец справочника

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

Так как лучше всего создавать справочники данных?

С командой по управлению данными

Совет по данным определяет инфраструктуру для справочников. Это может быть что-то простое как wiki страница, или Google spreadsheet или Excel с собранными вместе списком значений. При появлении инфраструктуры, начинайте работать с различными подразделениями в организации для популяризации справочников и выработки консенсуса о владельце данных и определений значений справочника. Заручитесь поддержкой людей работающими с этими данными, так как они как эксперты в этой области помогут вам в уточнении значений справочника и использования метрик данных. При этом убедитесь что заданные определения понятны всем, а не только людям работающим с этими значениями. 

Без команды по управлению данными

Что же делать в отсутствии команды. В маленькой организации вся ответственность может лечь на плечи одного человека. Хороший трехсторонний метод по внедрению справочников:

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

Итеративный подход: Основная цель собрать сообщество для создания документации. Например открытие чата в корпоративном мессенджере позволит собрать обратную информацию и организовать обсуждение.

Популяризуйте: Организуйте сообщество вокруг нового стандарта и соберите их требования. Напомните заинтересованным сторонам о важности стандарта. Расскажите на примерах историю о тех проблемах и мучениях которые были при отсутствии единых справочников. 

Сопровождение справочников данных

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

Следующая стадия потребует расширения, редактирования или даже замены полей данных. Изменения необходимы так как бизнес меняется сам, но к ним нужно подходить прагматично. Любые изменения или новые определения должны исходить от заинтересованной команды в организации с участием команда по управлению данными в реализации и информировании. Поддерживайте осведомленность в компании о предстоящих изменениях. Если возможно приведите примеры и старого и нового определения для метрик, опишите эффекты возможных изменений. Обязательно убедитесь что информация обо всех изменениях задокументирована и ведётся лог изменений.

Фреймворк справочников данных

1. Создавайте актуальную документацию по справочникам. Начните с разработки шаблона для описания поля. Минимально необходимый набор вопросов который нужно задать:

Что значит это поле? Какую метрику или какие данные это поле описывает? Как данные собираются? Какие инструменты используются для сбора? Это исходные данные или производились  вычисления? Данные преобразовывались или трансформировались перед записью? Кто владелец данных? Как связаться с владельцем?

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

1. Организуйте сообщество в корпоративном форуме или чате. Здоровое свойство любого управления справочниками данных это возможность организовать дискуссию о данных. Кроме непрекращающегося  сбора данных который происходит в режиме 24/7, люди запускают запросы в ночные часы и по выходным. Возможность коммуницировать через форум организации позволит демократизировать процесс общения.

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

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

Время на прочтение
18 мин

Количество просмотров 57K

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

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

Какие же принципы позволяют организовать систематическую работу со справочниками в 1С ERP?

Основные принципы работы

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

1. Однотипному основанию (в логике это понятие «основание деления»)
2. Только по одному основанию (признаку)

Типичными примерами нарушения принципов иерархичной классификации является выделение в справочнике «Номенклатура» групп (каталогов) вида «Зимняя коллекция» или пресловутые «Товары Марьи Степановны». В случае «Зимней коллекции» внутри этой группы обычно помещают подгруппы «Одежда», «Обувь», но в тоже время такие же подгруппы обычно уже есть в базовой подгруппе в другой ветви. Получаются пересекающиеся элементы и происходит дублирование элементов в справочнике. А причина в том, что при организации ветвей каталога был нарушен принцип однотипности основания – произведено деление одновременно по видовому признаку (одежда, обувь) и по ситуации (коллекция).

Здесь сразу же можно сказать, что в 1С ERP присутствуют справочники, которые позволяют решать подобные коллизии за счёт того, что они изначально спроектированы не под иерархическую структуру. Самый первый пример – справочник «Сегменты номенклатуры». Это справочник, позволяет собирать из элементов справочника «Номенклатуры» произвольные списки. При этом, один и тот же элемент номенклатуры может входить во множество списков. В частности через сегменты номенклатуры могут быть оформлены коллекции (но при этом следует помнить, что именно для коллекций есть отдельный справочник «Коллекции», который удобен для коллекций сезонного вида). Удивительно, но справочник «Сегменты номенклатуры» имеет иерархию каталогов, в которой принцип иерархичности должен соблюдаться.

Упрощая можно сформулировать: «Если справочник иерархический, то любой его элемент может входить только в одну ветвь (группу, каталог)» или иначе «Структура каталогов иерархических справочников не должна допускать пересечения разнотипных объектов в одной ветви (группе, каталоге).

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

Справочники и связанные с ними объекты

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

Перечисление «Типы номенклатуры»

Прежде всего, опорой номенклатурной системы справочников является перечисление «Типы номенклатуры». В нём всего несколько позиций: Товар, Тара, Услуга, Работа, Набор. У типов Товар и Услуга есть несколько подтипов, из которых особенное внимание следует обратить на продукцию, подлежащую маркировке и контрольные идентификационные знаки. Перечисление «типы номенклатуры» является элементом управления отдельными алгоритмами работы 1C ERP и поэтому недоступно для редактирования пользователем. На основе этого перечисления, пользователь имеет возможность организовать справочник «Виды номенклатуры».

Справочник «Виды номенклатуры»

На основе этого перечисления, пользователь имеет возможность организовать справочник «Виды номенклатуры». Справочник имеет иерархическую систему без ограничения уровней и доступен для заполнения пользователем. Но не следует тут же делать ошибку и формировать из справочника «Виды номенклатуры» разветвлённую структуру каталогов справочника «Номенклатура». Виды номенклатуры следует максимально ограничить именно видовыми признаками номенклатуры и сделать минималистичным.

Признак некорректности составления «видового» справочника – это желания вставить в наименовании элемента справочника определения, прилагательные, индексы. Справочник должен быть именно, что видовым и прилагательные допустимы только в случае, если понятие не имеет выраженности через одно слово (существительное). Например: в ряду «одежда», «обувь», «уборы головные», допустимо внести элемент «уборы головные», поскольку видового эквивалента «головным уборам» одним словом так просто не найти. Обозначить «Шапки» нельзя, т.к. шапка не видовое понятие, а разновидность головного убора наряду со «шляпой». Аналогично в машиностроении допустимо вид номенклатуры обозначать «лопасти», но определения «лопасти винтовые» и «лопасти турбинные» уже не относятся к справочнику «Виды номенклатуры».

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

1. Выделяет самые-самые общие «видовые» понятия номенклатуры. В том числе, отдельного вида номенклатуры требует номенклатура с отдельным типом номенклатуры (т.е. каждый используемый элемент справочника «Типы номенклатура» следует повторить в справочнике «Виды номенклатуры»).
2. Это классификатор по физическим свойствам.
3. Основной посыл создания нового вида — свой, особенный набор характеристик номенклатуры.
4. Также новый вид создаётся, если можно выделить свой набор фильтров по свойствам, который позволяет находить аналоги номенклатуры.
5. Отдельного вида номенклатуры требует номенклатура со своим сертификатом.
6. Отдельного вида номенклатуры требует номенклатура с отдельным набором товарных категорий.
7. Отдельного вида номенклатуры требует номенклатура с обязательной маркировкой ГИСМ.
8. Отдельного вида номенклатуры требует номенклатура с типом «контрольный идентификационный знак» (КИЗ).
9. Отдельного вида номенклатуры требуют импортируемые ТМЦ.
10. Отдельного вида номенклатуры требует номенклатура с общими параметрами учёта (например: ставка НДС) .
11. Отдельного вида номенклатуры требует номенклатура с общим набором свойств.

Перечисленные пункты, если они будут учтены при построении видов номенклатуры, обеспечивают корректную работу алгоритмов 1С ERP, по крайней мере, так как это описал разработчик (1С). Как видно, при соблюдении перечисленных критериев справочник видов номенклатуры может получиться весьма разветвлённым, чего следует максимально избегать и не плодить лишние сущности. Соответственно структуру видов номенклатуры не следует копировать в виде групп справочника «Номенклатура» для избегания избыточности.

Справочник «Товарные категории»

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

Предназначения этого справочника следующие:

1. Продолжение детализации «Видов номенклатуры».
2. Основной посыл создания товарной категории – категория конструирует код артикула для систем кодирования и штрихкодирования (ШК).
3. Категория определяет сущность и предназначение входящих в неё товаров.
4. Товарная категория служит основой распределения входящей в неё номенклатуры на характеристики номенклатуры.

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

Из сказанного выше и того что справочник «товарные категории» имеет иерархическую структуру, следует, что определение списка товарных категорий является нетривиальной задачей, если требуется соблюсти принцип иерархичности. Поэтому, чтобы её решить, организации следует разрабатывать товарные категории самостоятельно только при наличии в штате опытных товароведов, консультантов, маркетологов, а если таковых нет, товарные категории лучше составлять на основе общераспространённых классификаторов (ТНВЭД, ОКП, ОКВЭД, ОКДП и т.п.).

Поскольку к одному «Виду номенклатуры» может быть привязано несколько товарных категорий, то фактически все качественные определения, которые хотелось включить в вид номенклатуры, но по требованию принципа минимизации видов номенклатуры они не были включены в наименование вида, то товарные категории как раз и могут содержать описательные сущности номенклатуры (те самые «прилагательные», которые хотелось вставить в наименование вида). Например, вид номенклатуры «обувь», то категории могут быть «мужская обувь», «женская обувь», «детская обувь». И при этом же следует учитывать, что один элемент справочника «Номенклатура» входит только в одну товарную категорию. Таким образом, вид номенклатуры содержит список всех товарных категорий, которые могут быть по отдельности присвоены номенклатуре (элементу справочника номенклатуры), имеющей такой вид.

Справочник «Товарные категории» имеет очень существенное значение для системы планирования в 1С ERP. Именно к товарным категориям привязываются в документе «Норматив распределения планов продаж по категориям» распределения номенклатуры по характеристикам и реквизитам. Это распределение нужно, если компании с большим количеством номенклатуры необходимо исходный план продаж, составленный по товарным категориям, автоматически развернуть до номенклатуры и её существенных аналитик, включая характеристики номенклатуры. Распределение разворачивает товарные категории на все элементы справочника номенклатуры, которые имеют конкретную товарную категорию и одновременно детализируют до любого набора реквизитов и характеристик. Здесь значимость правильного конструирования товарных категорий возрастает нелинейным способом, т.к. позволяет составлять детализированные до номенклатуры и её реквизитов/характеристик планы продаж (в т.ч. с учётом распределения по сезонности, если используется функционал сезонности).

Справочник «Товарные характеристики»

Можно считать особой разновидностью товарных категорий «товарные характеристики». Это те свойства номенклатуры, которые имеют значение для покупателя (потребителя) в количественном выражении. Таким образом, следующий справочник номенклатурного блока «Характеристики номенклатуры» служит для описания тех параметров номенклатуры, по которым в системе следует иметь информацию о товарных остатках в количестве. Товарными характеристиками могут быть размер одежды, длина заготовки, качественный состав сырья и т.п. Количественные остатки в разрезе товарных характеристик являются опорными данными для выгрузки в интернет-магазины, внешние базы данных и т.п. Здесь важно не соблюдение иерархичности списка товарных характеристик, а невключение в характеристики тех параметров, которые для потребителя (покупателя) не имеют интереса в контексте количества – дабы избежать нагрузки на систему 1С в части учёта по количеству.

Теперь рассмотрим интересное следствие.

Если представим трёхосевую систему координат, где ось Х – вид номенклатуры, ось У – товарные категории, ось Z – набор (сочетание) товарных характеристик, то номенклатура будет своего рода функцией от Х, У, Z. Фактически эти три измерения задают не саму номенклатуру, а группу справочника «Номенклатура». Внутри каждой такой группы будет находиться номенклатура, отличающаяся дополнительными реквизитами и дополнительными сведениями. Собственно, сейчас мы сформулировали по какому принципу создавать группы номенклатуры, чтобы соблюсти системный подход. Это позволяет автоматически формировать группы каталогов справочника «Номенклатура» в тех случаях, когда обслуживается справочник с очень большим количеством записей или когда происходит перенос справочника на новую платформу или его перестроение.

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

Следует учесть, что каждый элемент справочника «Вид номенклатуры» содержит конструктор наименований номенклатуры. Наименование номенклатуры строится на основе реквизитов номенклатуры. Реквизитами, в частности, являются вид номенклатуры, товарная категория, сертификат. Поэтому логично, что в группу номенклатуры следует включать элементы с одинаковой товарной категорией. В 1С ERP типового функционала автоматического наименования самих групп справочника «Номенклатура» не имеется, поэтому он подлежит разработке в случае необходимости.

Исходя из своего опыта работы с 1С ERP могу сделать такой вывод: Справочники номенклатурного описания 1С ERP спроектированы таким образом, что самым важным становится не справочник «Номенклатура», а триада справочников «Вид номенклатуры», «Товарные категории», «Характеристики номенклатуры». Если эта триада спроектирована корректно, то справочник «Номенклатура», включая его группы, де-факто будет спроектирован.

Дополнительные реквизиты и сведения

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

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

Также несколько обособлен реквизит «Качество». Его назначение очень ограничено – им выделяют новую или бывшую в употреблении номенклатуру, степень износа. Но такой подход означает дублирование одной и той же номенклатуры в справочнике, что затрудняет выборку и различение сходных элементов справочника. Фактически происходит умножение сущностей, т.к. качество и его степени являются ситуационными состояниями. Целью организации не является производство некачественного товара или закупка некачественных сырья и материалов для запуска в производство. Поэтому для упрощения конструкции справочника «Номенклатура» и его содержимого, возможно, более правильным будет неиспользование реквизита «качество», а разделять разные по качеству ТМЦ учётными разделителями (субсчетами, складскими ячейками, сегментами номенклатуры и т.п.) и/или маркировкой. Для торговых организаций, где товары разного качества могут выступать таким же объектом торговли, этот совет менее актуален. Но для производственных предприятий, где товары (продукция) или материалы сниженного качества служат сырьем для производства имеет смысл выделить даже отдельный вид номенклатуры для такого повторного сырья и делать перевод из номенклатуры продаж/выпуска в номенклатуру сырья (например, операциями разукомплектации).

В рамках отступления от рассмотрения собственно справочников номенклатурного ряда также рассмотрим функционал «Фильтр по свойствам» справочников «Вид номенклатуры» и «Номенклатура». Фильтр по свойствам задаётся в виде номенклатуры как перечень реквизитов и дополнительных сведений. По этим свойствам в справочнике «Номенклатура» производится отбор сходных по назначению и сущности элементов номенклатуры. Поскольку для пользователя этот функционал выглядит как динамический отбор в форме справочника номенклатуры при выборе ссылки «Номенклатура с аналогичными свойствами» в элементе справочника «Номенклатуры», то он имеет значение лишь для быстрого поиска подобной номенклатуры в списках. Но если организовать хранение результатов таких отборов и продуманно составлять списки свойств отбора, то можно получить функционал похожий на типовой функционал «Номенклатура, продаваемая совместно». Например, производственные предприятия по номенклатуре производства могут организовать динамический отбор аналогов номенклатуры, допускаемой к замене в производственном процессе.

Функционал «Номенклатура, продаваемая совместно»

Сам же функционал «Номенклатура, продаваемая совместно» представляет собой алгоритм поиска в документах реализации и хранения результатов отбора в соответствующем регистре, по парам номенклатуры, которые встречается, с заданной пользователем частотой встреч в рамках одного документа оптовой/розничной реализации. Заполнение регистра возможно как автоматически по алгоритму, так и вручную прямым указанием пар номенклатуры. Подбор пар осуществляется с учётом характеристик номенклатуры и по настройке поиска ассоциаций в НСИ. В связи с тем, что этот функционал слабо управляем пользователем он имеет больше оценочно–вспомогательный характер для маркетинговых целей. Назначение этого функционала – выдавать подсказку менеджеру при оформлении подборов в документы реализации какие ещё товары можно предложить клиенту вдобавок к заказанному. Из этого видно, что если продажи организации формируются в отдельных билинговых системах или в интернет-магазинах, то описанный функционал малополезен.

Справочник «Производители»

Возвращаясь к справочникам рассмотрим справочник «Производители». Он представляет себе хранилище списка значений, выбираемых в реквизите номенклатуры «Производитель». Эти значения являются просто текстом и никак не связаны со справочником «Контрагенты». Нельзя сказать, что это весьма продуманное решение со стороны 1С, поскольку приводит к дублированию справочника «Контрагенты» и тем, кому в номенклатуре надо точно указывать производителя вплоть до юрлица придётся делать это указание в ещё одном дополнительном реквизите. Поэтому использовать справочник «Производители» стоит не для перечисления производителей-юрлиц, а для разделения по «видам» производителей. Например, стоит обязательно выделить группу «Наше производство» и указать наши центры производства, а внешних производителей выделять одним элементом «сторонние производители» или «иностранный производитель». В имени производителя нет даже смысла упоминать бренд, т.к. у номенклатуры есть отдельный реквизит «Бренд». Предложенное заполнение справочника «Производители» позволяет упростить справочники «Вид номенклатуры» и группы справочника «Номенклатура», т.к. их не надо дробить под производителя, но увеличивает число элементов справочника «Номенклатура», т.к. на каждый «вид» производителя заводится отдельный элемент номенклатуры. Предложенный подход будет полезен для организаций, продающих или производящих продукт, известный потребителю как объект, который производят разные организации, в частности купившие лицензию на производства определённой марки и т.п.

Справочник «Номенклатура поставщиков»

Со справочником «Производители» перекликается функционал «Номенклатура поставщика», в который входит справочник «Номенклатура поставщиков». Этот функционал привязан к справочнику «Партнёры» и позволяет, при включении соответствующей настройки в разделе «НСИ», сопоставлять элементы справочника «Номенклатура» отдельному справочнику, хранящему наименования номенклатуры поставщиков. Это очень важный и значимый функционал, значение которого трудно переоценить.

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

Во вторую очередь это важно для конструирования номенклатуры собственного производства и конструирования спецификаций, потому что организация получает возможность строить свой справочник «Номенклатуры» для сырья, материалов и полуфабрикатов вне зависимости от пула поставщиков, сложившегося на текущий момент, ни от изменений в пуле и в номенклатуре поставщиков в будущем. Отсюда появляется возможность более простого контроля затрат на производство, в т.ч. за счёт сокращения количества и трудоёмкости обслуживания спецификаций. Другими словами, производственникам и продающим товары одного бренда, поступивших от разных поставщиков/производителей, описанный функционал следует использовать в обязательном порядке. Иначе – преступление!

Справочник «Номенклатура поставщиков» является иерархическим и позволяет структурировать номенклатуру поставщиков под группировки своей номенклатуры или под независимые группировки поставщиков. Но здесь не требуется излишне усложнять классификацию номенклатуры поставщиков, т.к. привязка номенклатур производится однократно парно в самом функционале «номенклатуры поставщиков» или непосредственно в документах поступления ТМЦ, в которых группировка особого значения не имеет. В компаниях с большим потоком номенклатуры имеет смысл запретить привязку номенклатуры в документах поступления ТМЦ сотрудникам уровня «оператор», работающими с первичными документами, поскольку привязка требует гораздо более высокой квалификации и должна осуществляться отдельным специалистом (товароведом, инженером и т.п.) в функционале «номенклатура поставщика» в период заключения сделки (договора). Кроме того, связки номенклатур должны оперативно верифицироваться на актуальность при обработке новых модификаций прайс-листов поставщиков, до момента поставки. Функционал «номенклатуры поставщиков» используется в системе планирования 1С ERP при автоматическом создании из планов производства (потребностей в материалах) планов закупок и планов закупок из планов продаж по покупным товарам.

Также следует учитывать, что к номенклатуре поставщика привязан функционал «Цены поставщиков», что также актуально при планировании планов закупок, особенно в производствах с уникальным выпуском (кораблестроение, производство элитной мебели, отделка помещений и объектов), хотя в типовой 1С нет управляемого пользователем алгоритма подбора по ценам поставщиков при планировании.

Справочник «Ценовые группы»

Справочник «Ценовые группы» предназначен для ведения списка признаков, по которому отбирается номенклатура с одинаковыми методами ценообразования. Справочник не имеет по умолчанию иерархической структуры, поэтому подход к его наполнению должен быть минималистичным. Ценовая группа назначается, если для неё можно задать особую формулу расчёта (в справочниках «Виды цен» или «Скидки»). Но, поскольку два упомянутых справочника имеют независимые средства отбора номенклатуры можно сказать, что роль справочника «Ценовые группы» примитивна – всего лишь удобство отбора при назначении формул расчёта цен/скидок. Если все элементы номенклатуры при создании связывать с ценовыми группами, то гарантируется простота отбора по этому признаку.

Справочник «Сезонные группы номенклатуры»

Справочник «Сезонные группы номенклатуры» является справочником системы планирования и также является простым хранилищем списков, которые помогают разделить номенклатуру на группы с одинаковой сезонностью. К каждой созданной сезонной группе в регистре «Сезонные коэффициенты» хранятся коэффициенты распределения по месяцам года (Не по году/периоду планирования!!! А по месяцам календарного года). Справочник полезен, если планирование построено на первоначальном создании плана продаж на период (год) в целом по товарным категориям, а затем автоматически создаётся План продаж по номенклатуре с учётом сезонности и товарных характеристик. Но, если планирование продаж изначально строится на помесячном или более дробном плане продаж, то справочник сезонности не нужен, т.к. сезонность уже будет учтена в оборотах каждого месяца (недели).

Справочник «Политики учёта серий»

Справочник «Политики учёта серий» служит для привязки к виду номенклатуры правил работы с сериями номенклатуры и сроками годности. Политики учёта серий можно разделить на «лёгкие» (не требующие учета остатков или себестоимости в разрезе серий/сроков годности) и «тяжёлые» (требующие учета остатков или себестоимости в разрезе серий/сроков годности). Маркировку товаров и использование контрольных идентификационных знаков (КИЗ) 1С предлагает использовать в специально выделенном лёгком варианте типа политики «Маркировка продукции для ГИСМ». «Тяжёлого» учёта по возможности следует избегать, т.е. применять его обоснованно, в связи с тем, что серийный учёт предполагает крайне высокую нагрузку на производительность системы, особенно вариант с типом политики «Учёт себестоимости по сериям». В этом случае происходит лавинообразное увеличение количества вычислений, процессорных операций и число строк в табличных частях документов движения ТМЦ. Справочник политик учёта серий по умолчанию не является иерархическим, поэтому рекомендуется здравый минимализм при проектировании его элементов. Поскольку политики учёта серий привязываются к виду номенклатуры, то они распространяются на все элементы номенклатуры с заданным видом. Серийный учёт стоит вводить только в случаях, когда каждая единица продукции имеет уникальные отличия или когда применяется маркировка ГИСМ или собственная поштучная идентификация единиц продукции (например, RFID метками) или когда значения имеют сроки выпуска/годности. В остальных случаях использование серий с большой вероятностью является злоупотреблением возможностями 1С ERP и здравого смысла.

Справочник «Группы доступа номенклатуры»

Отдельно стоит упомянуть справочник «Группы доступа номенклатуры», который является простым списком видов доступа, которые описываются в профилях доступа. Следует помнить, что разделение доступа приводит к замедлению работы системы, поэтому этот справочник в общем случае не стоит использовать. Но он будет весьма полезен, если надо убрать с глаз пользователей оперативного звена элементы номенклатуры, переведённые в архив, выведенные из использования. Обычно применяют способ заведения отдельных групп каталогов для архивной номенклатуры в справочнике «Номенклатура», но это приводит к дублированию номенклатуры и усложнение отборов при выборке данных за прошлые периоды. Но если создать специальную группу доступа «Архив номенклатуры», то устаревшая номенклатура просто исчезнет из поля зрения тех пользователей, которым она в работе только мешает. Также можно завести отдельную группу доступа для новой проектируемой номенклатуры, принцип видимости аналогичный. Такой способ позволяет, не нарушая системности подхода к проектированию видов номенклатуры и справочника номенклатуры, выводить из оборота и вводить в оборот соответствующие позиции, сохраняя или сразу размещая их в нужных группах каталога.

Справочники «Коллекции», «Рейтинги продаж номенклатуры», «Квоты ассортимента» являются узкоспецифичными и предназначенными для розничной торговли ТНП, поэтому в настоящей статье их рассматривать не будем.

Резюме

1. Чтобы спроектировать справочник «Номенклатура» в 1С ERP необходимо и достаточно спроектировать справочники «Виды номенклатуры», «Товарные категории», «Характеристики номенклатуры».
2. Следует железно придерживаться описанного в статье принципа строгой иерархичности классификации для системного подхода к проектированию содержимого справочников и применения к ним математического аппарата.