В практике торговых компаний часто возникает ситуация, когда одна и та же номенклатурная позиция закупается у разных поставщиков или в разное время по разным ценам. В некоторых случаях руководство требует, чтобы эти различия сохранялись и в розничной продаже: например, чтобы в прайс-листе или на сайте Bitrix один и тот же "Ремень" отображался дважды с ценами 50 и 55 рублей. Однако стандартная архитектура 1С версии 10.3 (УТ 10.3) настроена на то, чтобы на конкретный момент времени у товара была только одна актуальная цена определенного типа.
В данной статье мы подробно разберем, почему возникает эта проблема, проанализируем структуру регистров 1С и рассмотрим несколько способов реализации задачи "нескольких цен для одного товара".
Для начала проанализируем работу основного механизма хранения цен в системе. Все цены в УТ 10.3 хранятся в регистре сведений ЦеныНоменклатуры. Этот регистр обладает двумя ключевыми свойствами:
Номенклатура, ТипЦен и ХарактеристикаНоменклатуры.Разберем ситуацию на примере. Если мы попытаемся провести документ УстановкаЦенНоменклатуры, где в табличной части указан один и тот же "Ремень" дважды с разными ценами, система при записи в регистр столкнется с конфликтом. Поскольку Номенклатура и ТипЦен (например, "Розничная") одинаковы, вторая строка просто перезапишет первую в пределах одной секунды (момента проведения документа). В итоге в базе останется только одна цена — последняя из документа.
Самым правильным и методически верным способом решения задачи в 1С 10.3 является использование механизма характеристик. Поскольку ХарактеристикаНоменклатуры входит в состав измерений регистра цен, ее использование позволяет создавать уникальные записи для одного и того же товара.
Рассмотрим пошагово, как это настроить:
Теперь при оформлении документа УстановкаЦенНоменклатуры мы сможем выбрать:
Преимущества этого метода:
Система воспримет эти строки как разные записи. В регистре ЦеныНоменклатуры появятся две строки, так как комбинация "Номенклатура + Характеристика" будет уникальной. Именно этот вариант лучше всего подходит для выгрузки на Bitrix, так как на стороне сайта характеристики станут SKU (Торговыми предложениями), и покупатель увидит один товар с возможностью выбора варианта по разной цене.
Проанализируем возможность использования серий. В Сообщении 20 автор упоминает, что поставщики отгружают товар разными сериями. Однако стоит помнить важный технический нюанс: в типовой конфигурации УТ 10.3 измерение СерияНоменклатуры отсутствует в регистре сведений ЦеныНоменклатуры. Серии используются для складского учета и партионного списания, но не для ценообразования.
Чтобы задействовать серии для хранения разных цен, программисту потребуется внести изменения в структуру метаданных:
СерияНоменклатуры в регистр ЦеныНоменклатуры.УстановкаЦенНоменклатуры, добавив в его табличную часть колонку "Серия".Внимание: Этот путь является трудоемким, так как повлечет за собой необходимость переделки всех отчетов по ценам, механизмов подбора в документах продажи (чтобы цена подтягивалась в зависимости от выбранной серии) и модулей интеграции с внешними системами.
Если руководство категорически против характеристик (например, чтобы не загромождать справочники), можно рассмотреть вариант добавления в регистр цен измерения, отвечающего за уникальность записи в рамках одного дня или документа. Рассмотрим логику добавления измерения ID_Записи или ДокументПоступления.
Если мы добавим в регистр ЦеныНоменклатуры измерение ДокументПартии (тип: ДокументСсылка.ПоступлениеТоваровУслуг), то система позволит хранить столько цен на один товар, сколько было документов поступления.
Для программной реализации в модуле проведения документа УстановкаЦенНоменклатуры код может выглядеть следующим образом:
// Пример модификации набора записей регистра цен
НаборЗаписей = РегистрыСведений.ЦеныНоменклатуры.СоздатьНаборЗаписей();
НаборЗаписей.Отбор.Регистратор.Установить(Ссылка);
Для Каждого СтрокаИзДокумента Из Товары Цикл
НоваяЗапись = НаборЗаписей.Добавить();
НоваяЗапись.Период = Дата;
НоваяЗапись.Номенклатура = СтрокаИзДокумента.Номенклатура;
НоваяЗапись.ТипЦен = ТипЦен;
// Наше новое гипотетическое измерение для уникальности
НоваяЗапись.ДокументПартии = СтрокаИзДокумента.ДокументПоступления;
НоваяЗапись.Цена = СтрокаИзДокумента.Цена;
НоваяЗапись.Валюта = Валюта;
КонецЦикла;
НаборЗаписей.Записать();
Однако помните, что такой подход "сломает" типовой механизм поиска цены. Стандартная функция Ценообразование.ПолучитьЦенуНоменклатуры() не будет знать, по какому именно ДокументуПартии ей нужно искать цену, и вернет либо ошибку, либо случайное значение. Вам придется переписывать всю логику получения цен в документах РеализацияТоваровУслуг и ЗаказПокупателя.
Рассмотрим вопрос выгрузки. Стандартный обмен 1С — Bitrix работает по протоколу CommerceML. Он ожидает, что цена привязана либо к объекту "Номенклатура", либо к объекту "Торговое предложение" (Характеристика).
Если вы пойдете путем Решения №3 (добавление своего измерения), стандартный модуль выгрузки просто "не увидит" эти цены или выгрузит только одну из них, так как он не обучен обрабатывать дополнительные измерения регистра.
Поэтому, если ваша конечная цель — Битрикс, настоятельно рекомендуем использовать именно Характеристики. В 1С 10.3 их можно настроить так, чтобы они создавались автоматически при поступлении товара с новой ценой. На сайте это будет выглядеть как один товар с выпадающим списком или разными кнопками выбора, что полностью соответствует бизнес-задаче.
Подводя итог, проанализируем лучший алгоритм действий для специалиста:
Помните, что попытка заставить 1С работать вопреки ее архитектуре (через добавление измерений в регистры сведений) всегда ведет к накоплению технического долга и сложностям при последующих обновлениях конфигурации.