Данная статья рассчитана на то, что читающий владеет понятием, что такое характеристика и с чем её едят, но позволю себе напомнить вам в двух словах о последствиях начала использования характеристик в базах данных. Когда на предприятии начинают вести учёт характеристик (благо если с начала ведения учёта), все таблицы, использующие справочник номенклатуры, сильно прибавляют в весе. Это связанно с тем, что появляется в алгоритмах работы использование ещё одной колонки. Не буду валить вас интегралами и, к примеру, возьму один из простейших, но наглядных:
Есть в УТ такое понятие, как "КлючиАналитикиУчетаНоменклатуры" - это элемент конфигурации типа Справочник, используемый 1с для многократного увеличения объёма базы и её неповоротливости ускорения работы регистров и структуризации данных. Хранятся в нём такие данные, как Номенклатура, характеристика, склад, серия. Таким образом объём хранимых данных в данном справочнике при простом учёте данных (без характеристик, серий, нескольких складов) = Номенклатура. Если мы ведём учёт по нескольким складам (мало вероятно что учёт ведётся по одному складу) объём (теоретически) КлючиАналитикиУчетаНоменклатуры = Номенклатура * склады. А если ко всему этому делу добавить характеристики то объём уже будет КлючиАналитикиУчетаНоменклатуры = Номенклатура * склады * характеристики. И упаси вас бог включить использование серий номенклатуры (что, кстати говоря, является тоже отдельным справочником, но это уже совсем другая история).
Такими нехитрыми формулами и расчётами мы можем понять как, с технической точки зрения, будет влиять включение ведения характеристик в базе. Стоит оговориться, что не все регистры и документы используют КлючиАналитикиУчетаНоменклатуры и в некоторых местах у нас просто будут "пачковаться" строки с номенклатурой и характеристикой.
Теперь я постараюсь "провангавать" и ответить на вопрос "Зачем нам избавляться от характеристик?". Характеристики, как правило, используются для обозначения цвета, размера и прочих свойств номенклатуры. Но иногда "специалисты" проявляют необразованность и идиотизм смекалку и фантазию и настраивают характеристики для обозначения партий или скажем принадлежности организации. Возможно, такие решения и несут в себе долю здравого смысла и в комбинации с опытными пользователями и внимательными операционистами приводят компанию к прозрачному и обширному учёту, увеличит аналитические мощности программы и все ваши запланированные цели достигнуты, а планы выполнены. Однако, если в схеме работы "сильный специалист - опытный пользователь - внимательный операционист" есть слабое звено то вероятнее всего весь учёт и в целом работа программы полетит в тартарары.
Вот мы и подошли к основной теме статьи Избавление от характеристик в УТ 11.2. Метод "Топора и педалей". Сам процесс не требует каких-то сверх человеческих сил и навыков супер специалиста по платформе 8.4. Практически всё можно сделать нехитрыми манипуляциями с функционалом платформы и конфигурации. Я бы выделил 3 основные этапа работы: удаляем, чистим, перенастраиваем. И перед тем как перейти к непосредственно разборам хотел бы отметить, что простое "отключение" галочки ведения учёта по характеристикам не спасёт отца русской демократии.
Удаление:
Это пока единственный этап на котором я использовал не типовой функционал. Тут, возможно, необходимо снять конфигурацию с поддержки (будет без этоо работать или нет - не проверял но это и не критично). Используя многолетний опыт программиста 1с, глубокие знания платформы я подготовил сложнейшую аналитическую обработку которая поможет нам избавиться от характеристик основной функциональный код примерно следующий:
&НаСервере
Процедура УбитьХарактеристикиНаСервере()
Характеристика = Справочники.ХарактеристикиНоменклатуры.Выбрать();
пока Характеристика.Следующий() Цикл
ХарОб = Характеристика.ПолучитьОбъект();
ХарОб.Удалить();
КонецЦикла;
КонецПроцедуры
Возможно, что понадобится разрешение на интерактивное удаление элементов характеристик, я на всякий случай сразу поставил роль. Теперь у нас на месте всех характеристик будут пустые ссылки.
Чистка:
Тут особо не о чем говорить, в конфигураторе запускаем механизм очистки битых ссылок со следующими настройками:
По завершению переходим к самому интересному этапу.
Перенастраивание:
Данный этап несёт в себе некоторые "подводные камни". Казалось бы - перепровели, "выключили галочки" и в путь к светлому будущему. НО не все механизмы УТ отключаются выключением настройки ведения учёта в разрезе характеристик. Как минимум везде где в форме с товарами добавлен реквизит "ХарактеристикиИспользуются" код лезет в общие модули которые потайными путями определяют это значение в истина или ложь в зависимости от значения Номенклатура.ИспользованиеХарактеристик и если оно отлично от Перечисления.ВариантыИспользованияХарактеристикНоменклатуры.НеИспользовать программа будет считать что нам нужно указать характеристику в таб. части. это произойдёт к примеру когда идёт обращение к настройкам обеспечения номенклатуры в заказах покупателей. Нам необходимо будет сделать групповое изменение реквизитов пройти по всем номенклатурам и установить данную настройку в нужное значение (для этого включите в настройке группового изменения реквизитов возможность менять системные поля и изменение в режиме обмена). Ещё важным моментом будет настройка характеристик в группах номенклатуры, если таковые используются, т.к. в случае перезаписи номенклатуры она может обратиться к своей группе и перезаполнить ИспользованиеХарактеристик.
Настройки для номенклатуры:
Закончив манипуляции со справочниками мы переходим к работе с документами. Тут ничего сложного нет, но стоит отметить, что если вы используете обмен данными с другими решениями рекомендую подвинуть дату регистрации изменений к обмену на начало следующего века для избежания казусов с отделом бухгалтерии.
На данном этапе после такой схемы обработки запущен пилотный проект который успешно прошёл все тестирование клиентом на объект расхождений с базой "оригиналом" и ошибок в выполнении бизнес процессов. Отчеты по товаром совпадают на 100% трудностей в выписке документов не имеется.