В практике крупных торговых компаний часто возникает ситуация, когда основная часть ассортимента продается по единому прайс-листу по всей стране, однако на определенную категорию товаров (например, скоропортящиеся продукты или товары с дорогой логистикой) необходимо устанавливать разные цены в зависимости от региона. В 1С:Управление нашей фирмой (УНФ) 1.6 существует несколько способов решения этой задачи: от стандартных настроек доработок конфигурации. Рассмотрим подробно каждый из них.
Это самый эффективный штатный метод, который позволяет минимизировать ручной ввод. Суть заключается в создании иерархии видов цен, где региональные цены автоматически наследуют значения из основной цены для всех товаров, кроме выбранной группы. Проанализируем этот алгоритм по шагам.
Компания — Все справочники — Ценовые группы и создадим новую группу, например, «Региональные товары». Укажем эту группу в карточках соответствующей номенклатуры.Основная цена (оптовая). В этот вид цены мы будем заносить стоимость товаров, актуальную для большинства регионов.Тип цены выберем значение Рассчитывать по другим видам цен (динамический или расчетный тип).[ОсновнаяЦена]. Это означает, что по умолчанию цена в регионе будет равна основной.[ОсновнаяЦена] * 1.1), либо оставить возможность ручного редактирования, если алгоритм отсутствует.Таким образом, при изменении Основной цены, региональные цены на 90% товаров обновятся автоматически, а «проблемная» группа останется под вашим ручным или формульным контролем.
Чтобы исключить человеческий фактор, когда менеджер в заказе покупателя забывает выбрать нужный региональный вид цены, воспользуемся механизмом привязки цен к структурным единицам. Проанализируем, как это работает в УНФ.
В карточке каждого склада или розничной точки (раздел Компания — Склады и магазины) есть реквизит «Вид цен». Если для склада «Казань» установить вид цены «Цена Казань», то при создании любого документа (Заказ покупателя, Реализация товаров и услуг), в котором выбран этот склад, программа автоматически применит региональные цены. Это избавляет от необходимости создавать «дубли» номенклатуры для разных городов.
Если штатных «уточнений» недостаточно, и требуется реализовать логику «Если региональная цена не задана — брать основную», можно прибегнуть к доработке. Мы можем создать расширение конфигурации, которое будет модифицировать запрос к регистру сведений ЦеныНоменклатуры.
Рассмотрим пример программной логики, которую можно реализовать в процедуре получения цен:
// Пример логики выбора цены с приоритетом
Функция ПолучитьДействующуюЦену(АктуальнаяНоменклатура, РегиональныйВидЦены, ОсновнойВидЦены)
// 1. Пытаемся получить цену по региональному виду
ЦенаРегион = Ценообразование.ПолучитьЦенуНоменклатуры(АктуальнаяНоменклатура, РегиональныйВидЦены);
Если ЦенаРегион <> 0 Тогда
Возврат ЦенаРегион;
КонецЕсли;
// 2. Если региональная цена не установлена, берем базовую
ЦенаБаза = Ценообразование.ПолучитьЦенуНоменклатуры(АктуальнаяНоменклатура, ОсновнойВидЦены);
Возврат ЦенаБаза;
КонецФункции
Такой подход позволяет хранить в базе только те региональные цены, которые реально отличаются от основных, не забивая регистр лишними записями.
Выясним еще одну интересную возможность УНФ — использование механизма автоматических скидок. Если цена в регионе отличается на фиксированный процент или сумму, удобнее использовать наценку, привязанную к условию.
Разберем, как это настроить:
Продажи.Выбор метода зависит от сложности вашей структуры:
Важный момент: избегайте создания дублей номенклатуры (например, «Товар (Москва)» и «Товар (Питер)»). Это приведет к коллапсу в складском учете и невозможности корректного анализа остатков. Всегда используйте одну карточку товара и разные виды цен.