В процессе работы с программой 1С:Управление торговлей 11.4 пользователи часто сталкиваются с необходимостью изменить Вид номенклатуры у уже созданных позиций. Система при этом выдает строгое предупреждение о возможных проблемах. Многие склонны игнорировать это сообщение, считая его простой формальностью. Однако за этим предупреждением стоят глубокие механизмы платформы, нарушение которых может привести к фатальным ошибкам в учете. Проанализируем ситуацию детально и выясним, какие именно «подводные камни» ожидают компанию при выполнении этой операции.
Одной из самых серьезных проблем является жесткая связка вида номенклатуры с Группой финансового учета (ГФУ). В УТ 11 настройки отражения в учете часто определяются именно через вид номенклатуры. Рассмотрим подробнее, что происходит при смене этого реквизита:
Себестоимость товаров перестают соответствовать новым настройкам в карточке.Рассмотрим крайний, но показательный случай: превращение товара в услугу или наоборот. Это действие вносит хаос в учет запасов. Если позиция была «Товаром», по ней велся количественный учет на складах в регистре Товары на складах. Как только вы меняете тип на «Услугу», система перестает «видеть» эту позицию на остатках, так как услуги не имеют физического остатка. При этом старые документы поступления все еще хранят записи о «товаре». Это приводит к тому, что вы не сможете корректно списать остатки, а инвентаризация будет показывать вечные расхождения.
Вид номенклатуры определяет, используются ли для товара Характеристики и Серии. Изменение этих настроек «задним числом» — одна из самых болезненных процедур. Разберем по шагам, к чему это ведет:
Если в новом виде номенклатуры настроена иная политика учета серий (например, была «Справочное указание», а стала «Управление остатками»), это заблокирует любое движение товара по старым документам. Вы не сможете оформить возврат от клиента или корректировку реализации без полной переделки всей цепочки документов. Система начнет требовать указание серий там, где их раньше не было в документах-основаниях.
Аналогичная ситуация с характеристиками. Если вы включаете характеристики для товара, у которого уже были продажи, старые записи в регистрах останутся «пустыми» (без характеристики). Новые документы будут требовать заполнения характеристики. В итоге в отчетах вы увидите две разные строки: одну пустую (старые остатки) и одну с характеристикой, которые не будут перекрывать друг друга.
Современные требования законодательства добавляют сложностей. Выясним причину, по которой нельзя просто поменять обычный товар на «Товар с маркировкой» (например, при переходе на обязательную маркировку одежды или обуви). В карточке при смене вида появляются обязательные поля для кодов ТН ВЭД и специфические настройки обмена с государственными системами. Проблема: остатки, которые уже лежат на складе, не имеют привязанных кодов маркировки. Система потребует сканирование марок при продаже, которых физически нет в базе для этой позиции. Простого изменения реквизита недостаточно — потребуется сложная процедура «Маркировки остатков».
Если ваша база 1С интегрирована с интернет-магазином (например, на Bitrix) или маркетплейсами, смена вида номенклатуры может изменить ID типа объекта или структуру передаваемых данных. Проанализируем ситуацию: алгоритм обмена часто опирается на метаданные объекта. Смена вида может привести к дублированию товаров на сайте или к ошибкам выгрузки цен и остатков, так как внешняя система воспримет товар с новым видом как совершенно новый объект.
Опытные пользователи и программисты иногда используют механизм разблокировки реквизитов или обработку «Групповое изменение реквизитов». Посмотрим на этот процесс:
В обработке можно включить опцию Показывать служебные реквизиты и Разрешить изменение реквизитов объектов. Это позволяет принудительно изменить ВидНоменклатуры, обходя стандартные проверки формы. Однако важно понимать: это не решает проблем с регистрами, а лишь скрывает симптом. После такого «силового» изменения часто требуется запуск регламентного задания Исправление ошибок в данных по фактическим остаткам, но даже это не гарантирует, что учет «схлопнется» корректно.
// Пример логики, которую выполняет система при проверке возможности изменения
Если ДокументыПоНоменклатуреСуществуют(СсылкаНаТовар) Тогда
Предупреждение("Вид номенклатуры изменить нельзя, так как есть движения по складским регистрам");
КонецЕсли;
Вместо рискованного изменения вида номенклатуры у позиций с историей движений, мы рекомендуем следующий алгоритм:
Если же по номенклатуре еще не было никаких движений (ни поступлений, ни заказов, ни остатков), изменять вид можно смело. Для этого в карточке товара нажмите Еще — Разрешить редактирование реквизитов и подтвердите действие. В этом случае система позволит внести правки без фатальных последствий для базы данных.
Подведем итог: изменение вида номенклатуры — это не просто смена «папки» или «описания», это изменение фундаментальных правил, по которым 1С рассчитывает налоги, прибыль и остатки. Всегда отдавайте предпочтение созданию новых позиций, если по старым уже ведется активная торговля.